AP
К тому же у шареда атомики, которые вроде нельзя отключить
Size: a a a
2020 December 17
M
Генту, например, тоже рекомендует только О2. Ну, я так понял, это дело вкуса
Для генты это актуально) ни у кого нет сил проверить все связки пакетов/компиляторов, поэтому безопасность важнее. Для отдельных приложений - изи
AT
а что за объекты? Если ты делаешь
shared_ptr<unique_ptr<float>>, то конечно надо беспокоиться о "количествах аллокаций". Если же ты какой-то ресурс в памяти держишь в такой конструкции, то надо трезво оценить как часто это разыменование и аллокации происходят — является ли это проблемой для производительности, или у тебя просто психологические проблемы преждевременной оптимизации в голове.AT
К тому же у шареда атомики, которые вроде нельзя отключить
в 2020 не завезли shared_ptr/shared_atomic_ptr? или что-то типа того
AP
это в пример того, где как раз таки я заюзал обобщенную фабрику для хендлов всех ресурсов, объектов, компонентов
Все что здесь перечислил
AP
То есть для условного объекта с физикой уже будет
object + rigid body component + rigid body resource + box collider component + collision object resource + mesh source component + mesh resource + mesh renderer component + material resource
object + rigid body component + rigid body resource + box collider component + collision object resource + mesh source component + mesh resource + mesh renderer component + material resource
AT
Все что здесь перечислил
ну то есть вряд ли атомики/лишние аллокации и т.п. являются проблемой
AT
ладно. Зависит от количества объектов. В общем получается вся проблема в том, чтобы повторить shared_ptr, который бы не был atomic
AP
ладно. Зависит от количества объектов. В общем получается вся проблема в том, чтобы повторить shared_ptr, который бы не был atomic
И убрать все лишние индирекции
AP
Потому что сейчас такой хендл в релизе просто обращается к массиву по индексу
AT
вот, кстати, интересный трюк в libstdc++:
template<typename T>
using shared_ptr_unsynchronized = std::__shared_ptr<T, __gnu_cxx::_S_single>;
AT
частично atomic операции убирает у shared_ptr
AT
AP
Я не знаю почему они не сделали ему какую-нибудь synchronization_policy
S
в 2020 не завезли shared_ptr/shared_atomic_ptr? или что-то типа того
А разве блок в шареде не на атомиках 0.о?
AT
А разве блок в шареде не на атомиках 0.о?
на атомиках. Именование конечно другое должно быть
TG
AP
для Эльбруса интерпретатор работал медленно из-за невозможности процессора предсказать переходы в ветвлениях.
Ы
d
а LGPL разрешает только динамическую линковку
Статически тоже можно
AT
Уменьшение количества изменений связано с тем, что новый компилятор LCC стал поддерживать стандарт С++17, и больше не надо было переписывать фрагменты кода, которые его использовали.мдя. Немного нового полезного добавили в C++17 похоже)