Ненавижу
автоматически рождающиеся объекты типа блокирующего 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: Jun. 1st, 2006 05:35 (UTC)А вообще приведенный тобой пример - это идеологический refcount, который как метод решения локальной задачи вполне применим. Я против refcount, который темплейтом оборачивает любой поинтер, даже если это локальная переменная с очевидным временем жизни несколько микросекунд.
no subject
Date: Jun. 1st, 2006 07:27 (UTC)Не в ref count зло, очевидно, но в ленности духа.
no subject
Date: Jun. 1st, 2006 07:51 (UTC)Руслан, Дима, вы серьезно верите, что ленность духа неминуемо следует из refcount и STL? ;)
no subject
Date: Jun. 1st, 2006 08:06 (UTC)Я видел много программистов и еще больше кода.
И - да - любой из пунктов выше плюс STL - это индекс рисков на ленность духа.
Но есть еще программисты, которым не нужен STL и smart ptr, потому что они дебилы и еще и мой пост прочли. И они будут теперь говорить, что smart ptr - это плохо, и поэтому они не будут даже разбираться, что это такое.
Чтобы уметь НЕ пользоваться, нужно сначала таки научиться пользоваться.
И про это хорошо пишет Гай Кавасаки.