Ненавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
no subject
Date: May. 30th, 2006 17:54 (UTC)Ресурсы, когда они не могут быть заранее упакованы.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
Обработка консольных команд, etc.
модель exception
А какие проблемы с исключениями, кроме вопросов эффективности конкретно в C++?
no subject
Date: May. 30th, 2006 22:38 (UTC)Консольные команды как отладочно-подстроечное средство - это очень специфичный проблемный случай [...]. А если весь игровой код висит на консольных командах - значит нужно менять что-то в дизайне игрового кода. Ты еще скажи, что у вас геймдизайн консольными командами настраивается.
В любом случае - обширное использование консольных команд равноценно скриптованию, а определение команд - интеграции. Подписчики на события в данном контексте - это результат смешения котлет и мух в голове, имхо.
Исключения
- мгновенны (не допускают откладывания обработки),
- жёсткий неуправляемый matching (класс-наследники vs regexp/шаблоны/тэгирование),
- непереносимы в другие контексты (потоки и т.п.),
- непреобразуемы без потерь на границе слоёв (C++),
- плохо соотносятся с созданием и никак - с уничтожением (C++),
- не всегда эффективны.
no subject
Date: May. 31st, 2006 01:51 (UTC)Консольные команды - вполне могут настраивать много гейм-дизайна. Дать вызывать скриптовые функции от Lua и превед. Легко добавлять тюнинг вместо значений в код - тем более. Иметь такие же глобальные регистрации и зависимости в базовых подсистемах (профайлер, консоль, etc) приятно и удобно.
Чем все это плохо - я слабо понимаю. Видимо, ты про более высокоуровневые завязки.
no subject
Date: May. 31st, 2006 16:08 (UTC)Кстати, можешь тоже привести примеры удачных refcountов ;)
А вот про консольные команды ты выступил куда-то не про то.
Речь шла, напомню, о примере, для чего полезны подписчики на события - для консольных команд.
Всё что ты написал - это либо то, что я назвал "отладочно-подстроечное средство", либо "использование - скриптование, определение - интеграция". То есть я не против, но "подписчики на события в данном контексте" - это от нищих духом, на самом деле.
Рад, что ты ничего не сказал про исключения.
no subject
Date: May. 31st, 2006 16:14 (UTC)no subject
Date: May. 31st, 2006 16:23 (UTC)У меня с религией проблем нет ;)
Хотя вот тут недавно видел локальное применение в поиске коллизий и был резок. Так что таки YMMV! :))
no subject
Date: May. 31st, 2006 16:27 (UTC)no subject
Date: May. 31st, 2006 21:01 (UTC)Все ответы в других ветках :)))
no subject
Date: May. 31st, 2006 08:13 (UTC)Не специфичный. Достаточно общий для тулсета.
Ты еще скажи, что у вас геймдизайн консольными командами настраивается.
Да, разумеется. Множество возможностей отладки, а также нахождение оптимальных коэффицентов (например, специфичные настройки AI) - всё это через консоль.
- не всегда эффективны.
Могут быть очень неэффективны (давать оверхед) в C++, особенно на консолях. Это и есть проблема. Что же касается реализации, то возможностей pattern matching, а также "исключений вверх" - действительно хотелось бы, но не в сказке живём, однако.
no subject
Date: May. 31st, 2006 16:12 (UTC)И не нужно, пожалуйста, путать геймдизайн и то, что я назвал "отладочно-подстроечными функциями".
Обычно после прикидочной настройки оно выносится либо в конфигурацию, либо в скрипт. Либо прибивается нахер.
Либо остаётся как подстроечная фишка - на уровне "цвет экрана смерти".
Про исключения - ты спросил, что мне нравится и не то согласился, не то хрен знает :))
no subject
Date: May. 31st, 2006 17:04 (UTC)no subject
Date: May. 31st, 2006 17:12 (UTC)Ну, если концепции не помогают в 90% случаев, а в оставшихся 10% - можно сделать иначе -- почему бы их не похаять-то? :)
А про "как по-моему правильно" - я не очень понял.
Ты имеешь ввиду - что бы я предложил использовать вместо каждого из пунктов "ненавижу-списка"?
no subject
Date: May. 31st, 2006 17:29 (UTC)Потому что я могу сделать "автоматически регистрирующиеся получатели сообщений" красиво, удобно и эффективно. Повесить на них даже input, например. Или подцепить какие-либо динамические сущности на автоматический refcount, управляющий не временем жизни, а временем активности, с последующим реюзом. Так что, данные концепции могут быть мне полезны.
Интересно описание вида "данную концепцию коряво использовали ТАК, хотя вместо этого надо было использовать совсем другие идеи ВОТ ТАК". Напишешь? :)
no subject
Date: May. 31st, 2006 20:59 (UTC)no subject
Date: May. 31st, 2006 22:01 (UTC)>- мгновенны (не допускают откладывания обработки),
>...
Когда какой-то из пунктов решающий - ну не используй того, что неудобно =)
Вот не "исключения всегда и везде". а "там где удобно".
Например, многие из вышеперечисленных пунктов меня не колеблют, так как совершенно не касаются меня. В частности:
>- жёсткий неуправляемый matching
>- непреобразуемы без потерь на границе слоёв (C++),
std::exception с what хватает на все случаи моей короткой жизни.
no subject
Date: May. 31st, 2006 22:14 (UTC)Я как раз наоборот - помните про КОГДА и про ГДЕ.
То есть ты знаешь моё отношение к one size fits all.
И мой список - он про конкретный size.