Помощники

[aruslan]

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

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

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

Comments

[aruslan.livejournal.com]

Ресурсы, которые не могут быть заранее упакованы - это очень специфичный проблемный случай, который не может быть широко виден по коду. Точнее он вообще не должен быть виден практически. А если виден - значит дело не в ресурсах, а в процессе. То есть в голове. То есть проблема.

Консольные команды как отладочно-подстроечное средство - это очень специфичный проблемный случай [...]. А если весь игровой код висит на консольных командах - значит нужно менять что-то в дизайне игрового кода. Ты еще скажи, что у вас геймдизайн консольными командами настраивается.
В любом случае - обширное использование консольных команд равноценно скриптованию, а определение команд - интеграции. Подписчики на события в данном контексте - это результат смешения котлет и мух в голове, имхо.

Исключения
- мгновенны (не допускают откладывания обработки),
- жёсткий неуправляемый matching (класс-наследники vs regexp/шаблоны/тэгирование),
- непереносимы в другие контексты (потоки и т.п.),
- непреобразуемы без потерь на границе слоёв (C++),
- плохо соотносятся с созданием и никак - с уничтожением (C++),
- не всегда эффективны.

[sim0nsays.livejournal.com]

refcount - может жить даже для подгруженных shared-ресурсов. Пожалуйста, только не надо ебать мозг про PC-платформу. Спекам не противоречит, сносно контролируется в препроцессе.

Консольные команды - вполне могут настраивать много гейм-дизайна. Дать вызывать скриптовые функции от Lua и превед. Легко добавлять тюнинг вместо значений в код - тем более. Иметь такие же глобальные регистрации и зависимости в базовых подсистемах (профайлер, консоль, etc) приятно и удобно.
Чем все это плохо - я слабо понимаю. Видимо, ты про более высокоуровневые завязки.

[aruslan.livejournal.com]

Про refcount см выше у шодана.
Кстати, можешь тоже привести примеры удачных refcountов ;)

А вот про консольные команды ты выступил куда-то не про то.
Речь шла, напомню, о примере, для чего полезны подписчики на события - для консольных команд.
Всё что ты написал - это либо то, что я назвал "отладочно-подстроечное средство", либо "использование - скриптование, определение - интеграция". То есть я не против, но "подписчики на события в данном контексте" - это от нищих духом, на самом деле.

Рад, что ты ничего не сказал про исключения.

[sim0nsays.livejournal.com]

Ну т.е. ты не возражаешь против локальных применений, и не любишь только глобально-идеологические, как у ddima? :)

[aruslan.livejournal.com]

Ну я конечно парень резкий, но не ебонат :)
У меня с религией проблем нет ;)

Хотя вот тут недавно видел локальное применение в поиске коллизий и был резок. Так что таки YMMV! :))

[sim0nsays.livejournal.com]

Тогда я повторю вопрос. Какие именно тебе не нравятся? Такие, чтобы и не по-большому, и не по-маленькому?

[aruslan.livejournal.com]

Это deadend, как я понял.
Все ответы в других ветках :)))

[justy-tylor.livejournal.com]

Ресурсы, которые не могут быть заранее упакованы - это очень специфичный проблемный случай
Не специфичный. Достаточно общий для тулсета.
Ты еще скажи, что у вас геймдизайн консольными командами настраивается.
Да, разумеется. Множество возможностей отладки, а также нахождение оптимальных коэффицентов (например, специфичные настройки AI) - всё это через консоль.
- не всегда эффективны.
Могут быть очень неэффективны (давать оверхед) в C++, особенно на консолях. Это и есть проблема. Что же касается реализации, то возможностей pattern matching, а также "исключений вверх" - действительно хотелось бы, но не в сказке живём, однако.

[aruslan.livejournal.com]

Если необработанные ресурсы - общий случай для runtime - то это тотальный пездец и про него я не говорю. Если ты про toolchain - то там я предпочитаю пейсать всё больше на C# - потею меньше ;)

И не нужно, пожалуйста, путать геймдизайн и то, что я назвал "отладочно-подстроечными функциями".
Обычно после прикидочной настройки оно выносится либо в конфигурацию, либо в скрипт. Либо прибивается нахер.

Либо остаётся как подстроечная фишка - на уровне "цвет экрана смерти".

Про исключения - ты спросил, что мне нравится и не то согласился, не то хрен знает :))

[justy-tylor.livejournal.com]

И опять всё сводится к тому, что "это мне не нравится, потому что хорошо не для всех случаев, и обычно делается через жопу". Ага. И C++, опять же, располагает к наиболее неестественным вариантам имплементаций. Не повод хаять концепции. Действительно, рассказал бы, как по твоему правильно. :)

[aruslan.livejournal.com]

> Не повод хаять концепции.
Ну, если концепции не помогают в 90% случаев, а в оставшихся 10% - можно сделать иначе -- почему бы их не похаять-то? :)

А про "как по-моему правильно" - я не очень понял.
Ты имеешь ввиду - что бы я предложил использовать вместо каждого из пунктов "ненавижу-списка"?

[justy-tylor.livejournal.com]

Ну, если концепции не помогают в 90% случаев, а в оставшихся 10% - можно сделать иначе -- почему бы их не похаять-то? :)

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

Интересно описание вида "данную концепцию коряво использовали ТАК, хотя вместо этого надо было использовать совсем другие идеи ВОТ ТАК". Напишешь? :)

[aruslan.livejournal.com]

Могу попробовать.

[http://users.livejournal.com/_winnie/]

>Исключения
>- мгновенны (не допускают откладывания обработки),
>...

Когда какой-то из пунктов решающий - ну не используй того, что неудобно =)

Вот не "исключения всегда и везде". а "там где удобно".
Например, многие из вышеперечисленных пунктов меня не колеблют, так как совершенно не касаются меня. В частности:
>- жёсткий неуправляемый matching
>- непреобразуемы без потерь на границе слоёв (C++),
std::exception с what хватает на все случаи моей короткой жизни.

[aruslan.livejournal.com]

Ммм, я ж не агитирую, что НИКОГДА и НИГДЕ, хвостатый :)
Я как раз наоборот - помните про КОГДА и про ГДЕ.

То есть ты знаешь моё отношение к one size fits all.
И мой список - он про конкретный size.