Исходное сообщение
"Обзор проблем в коде на C/C++, вызванных неопределённым пове..." Отправлено Аноним, 08-Июл-17 03:55
> Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий. Вы вообще программировали что-нибудь серьезное? Когда вы будете думать о том как гарантировать существование и своевременное уничтожение объекта в коде, архитектура которой прорабатывается сразу несколькими людьми, то вы будете думать над сроками жизни объекта. Все ваши "смарт поинтеры и соглашения" вылетают в трубу когда вам надо перестроить контроллеры и переработать часть архитектуры. Я вам на основе практического опыта скажу что самый лучший вариант в подобных случаях - передать управление временем жизни объекта контроллеру. Это позволяет менять архитектуру и код как угодно и во что угодно, не ограничивая себя неповоротливыми "best practices" и не расходуя время на создание ненужных контрукции только потому что в какой-то книжке кто-то написал что это "понятный любому квалифицированному плюсовику инструментарий". Плюсы: 1) самодокументируемый код снимяющий все неясности из-зя явных операции 2) управляющий код элементарен и может подводиться под условия (оптимизация, кеширование и прочее) 3) теперь граница жизни объекта оторвана от представления програмной конструкции, то есть можно делать что угодно с архитектурой (а мы ведь любим биндинги на другие языки?) и вам не надо думать о времени жизни объекта; можете считать это декомпозицией архитектуры Подобное делается просто на Си, С++ и любых других языках, и особенно в Java. Скорость исполнения не страдает.