1) скорее да, но это часть код стайла движка. Там вообще используется свой FORCEINLINE по аналогии с UE4 2) согласен 3) возразить не могу, но это тоже часть стайла 4) стайл 5) часть оптимизации, если есть предложения, будет интересно почитать 6) возможно не нужен, но не очень страшно 7) все нормально, как раз фича этого GC, что мы устойчивы к возникновению в коде обычных с++ указателей 8) + 9) + 10) соглашение в проекте 11) + 12) +, даже ускорит 13) + 14) нужно проверить с тестами производительности, не уверен, что будет быстрее 15) супер расширяемый код тоже не есть хорошо. В данном месте ровно столько, сколько нужно.
Верно, текущая версия не предусматривает использование GC в отдельном потоке. Сейчас он работает в основном по таймеру. Про выравнивание указателей - спасибо, еще место для оптимизации памяти.
Про плюсы перед shared_ptr я в статье затрагивал, но GC, это другой подход к контролю памяти в принципе. Поэтому их некорректно сравнивать.
Потому что с GC мы получаем возможность спрашивать валидность объекта не только сильной, но и слабой ссылки после удаления объекта. Тут не будет проблемы, если мы создадим случайно несколько разных "умных" указателей на один объект.
Скорее это фича именно для геймплейной логики в с++, где хочется не думать о жизни объекта.
Думаю, что в с++ можно получить "2 в 1". Полный контроль на низком уровне и использование GC на высоком. Без него очень противно создавать объект не привязанный к миру(аналогия на UObject из UE).
1) Про использование new не понял вопроса. В общем случае количество объектов может быть большим, и мы не хотим переполнить стек. 1 лям, даже интов, класть на стек, что-то не хочется. 2) Согласен, можно использовать vector для bool, он тоже их пакует. 3) В статье представлен не финальный вариант. В движке большая часть интов заменены на беззнаковый вариант.
4) Этот gc не будет работать в отдельном потоке, об этом речи и не шло. Многопоточная тут только сборка мусора на вызов ForceGC.
1) скорее да, но это часть код стайла движка. Там вообще используется свой FORCEINLINE по аналогии с UE4
2) согласен
3) возразить не могу, но это тоже часть стайла
4) стайл
5) часть оптимизации, если есть предложения, будет интересно почитать
6) возможно не нужен, но не очень страшно
7) все нормально, как раз фича этого GC, что мы устойчивы к возникновению в коде обычных с++ указателей
8) +
9) +
10) соглашение в проекте
11) +
12) +, даже ускорит
13) +
14) нужно проверить с тестами производительности, не уверен, что будет быстрее
15) супер расширяемый код тоже не есть хорошо. В данном месте ровно столько, сколько нужно.
Верно, текущая версия не предусматривает использование GC в отдельном потоке. Сейчас он работает в основном по таймеру.
Про выравнивание указателей - спасибо, еще место для оптимизации памяти.
Про плюсы перед shared_ptr я в статье затрагивал, но GC, это другой подход к контролю памяти в принципе. Поэтому их некорректно сравнивать.
Потому что с GC мы получаем возможность спрашивать валидность объекта не только сильной, но и слабой ссылки после удаления объекта. Тут не будет проблемы, если мы создадим случайно несколько разных "умных" указателей на один объект.
это сишный массив листов, возможно плохо акцентировал внимание.
Размер forward_list 16 на 86-64. forward_list используется в мапе по структуре из пункта 2. Стек тоже не выдержит лям forward_list.)
Скорее это фича именно для геймплейной логики в с++, где хочется не думать о жизни объекта.
Думаю, что в с++ можно получить "2 в 1". Полный контроль на низком уровне и использование GC на высоком. Без него очень противно создавать объект не привязанный к миру(аналогия на UObject из UE).
1) Про использование new не понял вопроса. В общем случае количество объектов может быть большим, и мы не хотим переполнить стек. 1 лям, даже интов, класть на стек, что-то не хочется.
2) Согласен, можно использовать vector для bool, он тоже их пакует.
3) В статье представлен не финальный вариант. В движке большая часть интов заменены на беззнаковый вариант.
4) Этот gc не будет работать в отдельном потоке, об этом речи и не шло. Многопоточная тут только сборка мусора на вызов ForceGC.