?

Log in

No account? Create an account
Помощники - Valse oubliée [entries|archive|friends|userinfo]
aruslan

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]
[ delicious | aruslan's delicious ]

Links
[Links:| Tags Profile Friends FG1 PP gamedev XNA FF Entries Comments Memories ]

Помощники [May. 30th, 2006|03:06 pm]
aruslan
[Tags|, , , , ]

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

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

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

Comments:
[User Picture]From: justy_tylor
2006-05-30 05:54 pm (UTC)
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
Ресурсы, когда они не могут быть заранее упакованы.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
Обработка консольных команд, etc.
модель exception
А какие проблемы с исключениями, кроме вопросов эффективности конкретно в C++?
(Reply) (Thread)
[User Picture]From: aruslan
2006-05-30 10:38 pm (UTC)
Ресурсы, которые не могут быть заранее упакованы - это очень специфичный проблемный случай, который не может быть широко виден по коду. Точнее он вообще не должен быть виден практически. А если виден - значит дело не в ресурсах, а в процессе. То есть в голове. То есть проблема.

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

Исключения
- мгновенны (не допускают откладывания обработки),
- жёсткий неуправляемый matching (класс-наследники vs regexp/шаблоны/тэгирование),
- непереносимы в другие контексты (потоки и т.п.),
- непреобразуемы без потерь на границе слоёв (C++),
- плохо соотносятся с созданием и никак - с уничтожением (C++),
- не всегда эффективны.
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 01:51 am (UTC)
refcount - может жить даже для подгруженных shared-ресурсов. Пожалуйста, только не надо ебать мозг про PC-платформу. Спекам не противоречит, сносно контролируется в препроцессе.

Консольные команды - вполне могут настраивать много гейм-дизайна. Дать вызывать скриптовые функции от Lua и превед. Легко добавлять тюнинг вместо значений в код - тем более. Иметь такие же глобальные регистрации и зависимости в базовых подсистемах (профайлер, консоль, etc) приятно и удобно.
Чем все это плохо - я слабо понимаю. Видимо, ты про более высокоуровневые завязки.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 04:08 pm (UTC)
Про refcount см выше у шодана.
Кстати, можешь тоже привести примеры удачных refcountов ;)

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

Рад, что ты ничего не сказал про исключения.
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 04:14 pm (UTC)
Ну т.е. ты не возражаешь против локальных применений, и не любишь только глобально-идеологические, как у ddima? :)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 04:23 pm (UTC)
Ну я конечно парень резкий, но не ебонат :)
У меня с религией проблем нет ;)

Хотя вот тут недавно видел локальное применение в поиске коллизий и был резок. Так что таки YMMV! :))
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 04:27 pm (UTC)
Тогда я повторю вопрос. Какие именно тебе не нравятся? Такие, чтобы и не по-большому, и не по-маленькому?
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 09:01 pm (UTC)
Это deadend, как я понял.
Все ответы в других ветках :)))
(Reply) (Parent) (Thread)
[User Picture]From: justy_tylor
2006-05-31 08:13 am (UTC)
Ресурсы, которые не могут быть заранее упакованы - это очень специфичный проблемный случай
Не специфичный. Достаточно общий для тулсета.
Ты еще скажи, что у вас геймдизайн консольными командами настраивается.
Да, разумеется. Множество возможностей отладки, а также нахождение оптимальных коэффицентов (например, специфичные настройки AI) - всё это через консоль.
- не всегда эффективны.
Могут быть очень неэффективны (давать оверхед) в C++, особенно на консолях. Это и есть проблема. Что же касается реализации, то возможностей pattern matching, а также "исключений вверх" - действительно хотелось бы, но не в сказке живём, однако.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 04:12 pm (UTC)
Если необработанные ресурсы - общий случай для runtime - то это тотальный пездец и про него я не говорю. Если ты про toolchain - то там я предпочитаю пейсать всё больше на C# - потею меньше ;)

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

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

Про исключения - ты спросил, что мне нравится и не то согласился, не то хрен знает :))
(Reply) (Parent) (Thread)
[User Picture]From: justy_tylor
2006-05-31 05:04 pm (UTC)
И опять всё сводится к тому, что "это мне не нравится, потому что хорошо не для всех случаев, и обычно делается через жопу". Ага. И C++, опять же, располагает к наиболее неестественным вариантам имплементаций. Не повод хаять концепции. Действительно, рассказал бы, как по твоему правильно. :)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 05:12 pm (UTC)
> Не повод хаять концепции.
Ну, если концепции не помогают в 90% случаев, а в оставшихся 10% - можно сделать иначе -- почему бы их не похаять-то? :)

А про "как по-моему правильно" - я не очень понял.
Ты имеешь ввиду - что бы я предложил использовать вместо каждого из пунктов "ненавижу-списка"?
(Reply) (Parent) (Thread)
[User Picture]From: justy_tylor
2006-05-31 05:29 pm (UTC)
Ну, если концепции не помогают в 90% случаев, а в оставшихся 10% - можно сделать иначе -- почему бы их не похаять-то? :)

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

Интересно описание вида "данную концепцию коряво использовали ТАК, хотя вместо этого надо было использовать совсем другие идеи ВОТ ТАК". Напишешь? :)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: _winnie
2006-05-31 10:01 pm (UTC)
>Исключения
>- мгновенны (не допускают откладывания обработки),
>...


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

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

std::exception с what хватает на все случаи моей короткой жизни.




(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 10:14 pm (UTC)
Ммм, я ж не агитирую, что НИКОГДА и НИГДЕ, хвостатый :)
Я как раз наоборот - помните про КОГДА и про ГДЕ.

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