Реквест книг, примеров по работе с памятью, современному стилю C++

игровой-движок
подсчет ссылок

«you're doing it wrong» (c)

Для игр используют свои аллокаторы, пулы и тд.

shared_ptr противоречит использованию своего аллокатора?

Насколько я помню, он использует атомарный счётчик ссылок - о какой производительности может идти речь?

Ну и свой аллокатор может сам заботится о памяти, которую сломает shared_ptr.

Насколько я помню, он использует атомарный счётчик ссылок

...которые меняются при создании/уничтожении копий

- о какой производительности может идти речь?

О высокой.

Ну и свой аллокатор может сам заботится о памяти, которую сломает shared_ptr.

Аллокатор - не может. Сборщик мусора - может, но это не аллокатор. Так что вопрос в силе - чем свои аллокаторы и пулы противоречат shred_ptr?

На ObjC везде подсчет ссылок - вроде производительности не сильно мешает. Но я скажу что производительность движка для меня лично не главное, главное проникнуться сутью нового c++, читаемость кода.

CppCoreGuidelines, Scott Meyers «Effective Modern C++»

спасибо

...которые меняются при создании/уничтожении копий

Не распарсил.

О высокой.

По сравнению с чем? Использования обычных RC, или не использование их вообще будет еще быстрее.

Аллокатор - не может.

Почему это? Берём первый попавшийся C++ Memory Pool Allocator и видим, что он сам освобождает память при выходе из области видимости.

Не распарсил.

Бывает.

Использования обычных RC, или не использование их вообще будет еще быстрее.

Конечно. На перенебрежимо малую долю общей производительности.

Берём первый попавшийся C++ Memory Pool Allocator и видим, что он сам освобождает память при выходе из области видимости.

shared_ptr может ссылаться и на такой объект, и даже проверять корректность использования пула в deleter.

shred_ptr

Хорошее название для умного указателя, который при удалении затирает память объекта.

пулы

За термином «пул» стоят как минимум два разных понятия. Один из тех дурацких терминов, постоянно вызывающих недопонимания.

На перенебрежимо малую долю общей производительности.

Банальный бенчмарк запросто даст двухкратный прирост. Но тут можно развести демагогию о том, что просто нужно по ссылке передавать, чтобы часто не вызывать конструктор копирования shared_ptr. Но это не делает ARC (который atomic) быстрым. Под быстрым я подразумеваю простой int.

shared_ptr может ссылаться и на такой объект, и даже проверять корректность использования пула в deleter.

Но смысл от наворотов shared_ptr, если аллокатор уже всё делает? Только лишние расходы.

Банальный бенчмарк запросто даст двухкратный прирост

Поэтому я сказал об общей производительности программы.

Но смысл от наворотов shared_ptr, если аллокатор уже всё делает?

Проверка корректности использования пула.

Ага, а потом все течет и падает

Так что вопрос в силе - чем свои аллокаторы и пулы противоречат shred_ptr?

Какой смысл считать ссылки на память в пуле? Создал пул, нарожал объектов, поигрался и снёс всё к чертовой матери — в этом вся философия же.

Какой смысл считать ссылки на память в пуле?

Последнее предложение здесь.

Банальный бенчмарк запросто даст двухкратный прирост.

Очевидно, что любое нормальное приложение не состоит из бесконечного цикла, делающего только new и delete. А обычно между new и delete ещё и огромный объём работы. Соответственно, есть мнение, что затраты на выделение/освобождение памяти не являются основными для игрового движка. А если являются, то что-то в архитектуре приложения не так (надо использовать пулы и подобные вещи).

Сомнительная польза за высокую цену.

В чем измерена высота цены?

Дёрганье реф каунтеров.

Или локальные кучи для всех потоков (можно с rc или сборщиком мусора) + общую кучу с arc для IPC.

И много ты видел многопоточных движков? Ну где этох самых потоков хотя бы больше 2 (на фоновые задачи и рендер), и такая оптимизация действительно чем-то поможет.

https://www.ozon.ru/context/detail/id/34747131/