?

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: ddima
2006-05-30 05:51 pm (UTC)
+1 (автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса).

+1 (автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок).
Уж если объект умер,дайте ему умереть спокойно. Если кто-то хочет на него смотреть во время гибели, дайте ему извещение "оно умерло". Путь дольше этот кто-то сам что хочет, то и делает со своей ссылкой.

-1 (автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений).
Руслан, а их-то за что? Короче, надеюсь, мы с с тобой еще подискутируем на эту тему. Хотя в unbound есть и свое зло :)

+1 (автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main()).
См. пост выше.

мгновенность, нераспределенность, модель exception, lower-order programming.
Жопой чувствую, что надо тоже написать "+1" но тема нифига не раскрыта.
(Reply) (Thread)
[User Picture]From: aruslan
2006-05-30 11:10 pm (UTC)
> -1 (автоматически регистрирующиеся получатели сообщений.
> И unbound рассылку сообщений).

Ну тут ключевые слова автоматически и unbound.
То есть во всех известных мне местах рассылки сообщений
- дробили одно сообщение на цепочку сообщений (из-за бардака)
- вводили правила приоритетов на сообщения (из-за бардака и проблем)
- чётко разделяли сообщения на получателей (кто когда именно)
- выясняли, что делать, если получатель удаляется или создается в процессе
- выясняли, как прекратить дальнейшую обработку
- заменяли на прямые вызовы, потому что уже и так всё понятно.

То есть к концу возникало чёткое понимание, где же именно точка расширения или хука в системе.
(Reply) (Parent) (Thread)
[User Picture]From: ddima
2006-05-31 04:12 am (UTC)
Ну, с приоритетами согласен, пришлось помудохаться, и я даже сейчас не до конца понимаю, как это должно выглядеть в идеале :)
"что делать в процессе" - вроде тоже проблем не возникало.

вообще если какая-то подписанная на сообщения сущность создается/уничтожается/получает сообщения на один фрейм раньше или позже, ей должно быть пофигу. Она свою задачу рано или поздно выполнить. Просто размажет цикд выполнения по нескольким шагам :)
А вообще событийно-управляемая система - это религия, да. Увы, в Крейте некоторые так до сих пор эту науку и не впитали.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 04:04 pm (UTC)
Ну, Дима, я ж не против событийно-управляемой системы!
Я против неуправляемой! ;)
(Reply) (Parent) (Thread)