hirthwork
14.12.2012 09:54 mcabber
таки большинство GoF паттернов смотрятся более гармонично именно на языках с garbage collector'ом. на всяких плюсах приходится городить shared_ptr, которые суть являются ошибкой проектирования
21 comment
recommend
bookmark
subscribe
паттерны + java
яблоки + perl
почему шареды — ошибка проектирования?
я ж тебе уже объяснял и ты уже соглашался: шареды означают что ты сам толком не понимаешь кто у тебя владеет объектом и какого его время жизни. из умных поинтеров толковый только unique_ptr
> подразумевая, что владение необходимо
штобля:?
питонобля:?
подожди. сраться вдвоём в отдельном треде будете, а мне пока ещё интересно понять что он хотел этим сказать
в общем, насчёт shared_ptr ты прав; но у меня ощущение, что отношение лайфтаймов на объектах не равноценно и, может быть, даже не выражается через отношения владения на них же.
Короче, блджад, отказываться от автоматического управления памятью — это ошибка проектирования, а не shared_ptr сам по себе.
так вы определитесь. Отказ от shared_ptr плохо или хорошо? А то ты говоришь, что отказа от shared_ptr — хорошо, а от автоматического управления памятью — нет.
использование shared_ptr — плохо
в случае когда хуй поймёшь, какой из объектов должен владеть куском памяти — куском памяти должен владеть контекст, в котором эти объекты созданы
научись уже размышлять чуть поразнообразнее, чем «это хорошо/это плохо».
научишь приводить логическисвязанные заключениея, а не те, в которых одна часть противоречит другой // ппц ты тупой
а если этот самый контекст — это вся программа? подразумевая соответсвующие лайфтаймы.
Тогда что, созравать ProgramExecutionContextSingleton, и навешивать овнершип на него? :D
лучше бы ты понимать научился, вместо того чтобы искать противоречия.
я не могу представить себе ситуацию, когда одновременно нужно подобие shared_ptr и при этом минимальным контекстом, в котором требуется этот shared_ptr является вся программа.
Singleton — это почти всегда нехорошо.
s/почти //
на эту реакцию и был рассчёт же :)
алсо, что-то не смог придумать примеров для /15. Во-первых, лайфтайм занятого ресурса должен заканчиваться не раньше, чем таковой занявшего его контекста (иначе контекст напрямую овнит ресурс, композицией там или unique_ptr к примеру; нет смысла в shared ownership) — и в случае, когда контекст является сабжевой программой, лайфтайм ресурса, очевидно, не может превосходить лайфтайм контекста. Говно, короче, я хуйню спизданул.
бля. сколько текста ради последних трёх слов.