Помощники

[aruslan]

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

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

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

Comments

[aruslan.livejournal.com]

/me криво ухмыльнулся

Тогда ты применяешь патентованную технологию INFINITRAX!

[zemedelec.livejournal.com]

Да, Руслан.
Стратегия, load on demand, 15 расс, из которъх рандомнъе 8 всегда на диске.
Тогда пользуется популярнъй паттерн: "неможеш стримить -> load on demand" :)
Конечно, ето не ref_count нужен, если на PC, ибо факт существования только нужен, в остальном virtual memory спасает, въгрузит все device вместе с heap-ом... :)

[aruslan.livejournal.com]

Сергей, я действительно звучу так категорично?
Воистину - дай стеклянный хуй и дальше по списку :))

Я не против load on demand.
Я против ленности и слепоты.

Просто опыт показывает - видишь pull-модель, видишь load-on-demand, видишь иерархическую object system - можно уже начинать спрашивать "почему".
И, к сожалению, в 80% случаев ответ - потому что лень.

"Не потому что, с нею нам светло, а потому - что с ней не нужно света."

[zemedelec.livejournal.com]

Нене, я согласен, по большому счету всегда можно лучше, "каждъй следующий движок будет меньше и бъстрее!".
Да, но одно лень, а другое - лень сидеть пол-года ночами, имплементируя на досуге load inplace, стриминг, бандлование даннъх и т.д.
Ибо на работе такое рассценивается как трата времени, на сей момент, совсем так, тривиально.

[aruslan.livejournal.com]

Если на работе такое расценивается как пустая трата времени - возможно, имеет смысл подумать о том, что тебе интересно в жизни ;)