Помощники

[aruslan]

Ненавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().

мгновенность, нераспределенность, модель exception, lower-order programming.

Но научить правильно не всегда получается.

Comments

[ddima.livejournal.com]

Саймон, ты лучше расскажи, где тебе refcount уж совсем нужен. Просто я (за своей умственной ограниченностью) все годы ухитрялся обойтись без него, поэтому мои примеры непоказательны :)

[sim0nsays.livejournal.com]

Дима, я боюсь с тобой говорить на эту тему. Если уж не видно смысла в динамических аллокациях во время работы игры вообще - то про рефкаунт даже говорить не удобно.

Тот пример, какой я привел - кажется совсем глупым?

[aruslan.livejournal.com]

Саймон, у меня были динамические аллокации - загрузка.
Но рефкаунтов всё равно не было.

Правда, расскажи за sine qua non!

[sim0nsays.livejournal.com]

И никаких кроме загрузки не было?
И те - именно один на чанк?
Уважуха. Давай ты еще меня добьешь и скажешь, что пулов не было вообще. И патиклы летали группами по ровно 20.

[aruslan.livejournal.com]

Почему же :)
Пулы были. Кэши были.
Размеры партикл систем были известны, конечно, заранее.

Операторов new во время собственно retail игры, насколько я помню, таки не было совсем. Но могу легонько приврать.
Впрочем, assertы вроде ближе к релизу не срабатывали.

[sim0nsays.livejournal.com]

Ну отлично. Пулов и кешей для объектов разных размеров и природы - типа совсем не было? Каждая подсистема всегда жрала памяти столько, сколько можно сожрать в худшем случае?

[aruslan.livejournal.com]

Пулы и кэши были.
Даже стеки были. На каждый поток.
Я не говорю, что каждый выделил себе по максимуму на всякий случай (хотя, кстати, в каких-то местах это близко к правде).
Я говорю, что максимум этот определен, и суммарный максимум тоже и от него пляшешь.

Когда я говорю "динамическое выделение", я имею ввиду Васю Пупкина с немытой попой, когда он делает v.push_back() или создает какой-нибудь string или того хуже hashmap.

Ну или там std::vector в функции просто чтобы ему напомнили, если он индексы неправильно посчитает, а boost::array не подходит, потому что требует фиксированного размера.

[ddima.livejournal.com]

Пример вполне жизненный, если бы не одно "но". Shared кусочки с непонятным временем жизни занимают непонятный объем памяти. А я со своей хронической нелюбовью к аллокациям непонятного размера хочу точно знать, когда и что мне надо загружать. Поэтому заменяю refcount на понятие "объекты этой группы ссылаются на общий блок". И веду проверку на препроцессоре, что не дай бог, возникнет ситуация с одновременно двумя блоками.

А вообще приведенный тобой пример - это идеологический refcount, который как метод решения локальной задачи вполне применим. Я против refcount, который темплейтом оборачивает любой поинтер, даже если это локальная переменная с очевидным временем жизни несколько микросекунд.

[aruslan.livejournal.com]

Вот кстати ты правильно сказал.
Не в ref count зло, очевидно, но в ленности духа.

sim0nsays, понимаешь?

[sim0nsays.livejournal.com]

Ага. Видимо, про это все время и спорят с Димой за STL. Про бренность духа, а не про std::
Руслан, Дима, вы серьезно верите, что ленность духа неминуемо следует из refcount и STL? ;)

[aruslan.livejournal.com]

Всё немного страшнее, Семён.

Я видел много программистов и еще больше кода.
И - да - любой из пунктов выше плюс STL - это индекс рисков на ленность духа.

Но есть еще программисты, которым не нужен STL и smart ptr, потому что они дебилы и еще и мой пост прочли. И они будут теперь говорить, что smart ptr - это плохо, и поэтому они не будут даже разбираться, что это такое.

Чтобы уметь НЕ пользоваться, нужно сначала таки научиться пользоваться.
И про это хорошо пишет Гай Кавасаки.