есть очень простой принцип, которому стоит следовать в большинстве (если не во всех) случаев: ответ на вопрос о владении объектом должен быть очевиден, всё остальное - способы достижения этой очевидности
(под владением подразумевается, кто должен удалить этот объект)
а способы такие:
1. стековые объекты
2. boost::shared_ptr, boost::scoped_ptr, std::auto_ptr
3. близость создания и удаления в коде
4. документация (имена функций, переменных, комментарии)
(попробовал упорядочить по "степени надёжности", но это может быть субъективно)
в некоторых случаях последний способ не так уж и страшен
например, паттерн "фабрика" часто как раз и предполагает наличие метода, который создаёт объект, но удалением занимается кто-то другой (возможно, даже не метод этой фабрики)
использовать умные указатели на этом уровне не всегда хорошо, т.к. каждый тип умного указателя навязывает свою стратегию владения, а иногда это решение стоит отдать пользователю кода, который создаёт объекты
так что в таких случаях можно, например, назвать функцию CreateConcatenatedString, по названию вполне понятно, что строка была создана, а значит, вызывающий код ответственен за её удаление
чтобы выделить память заранее, пришлось бы вынести часть логики, специфичной для функции сложения (вычисление длины) наружу, а это тоже не очень хорошо
в большинстве же случаев, конечно new и delete стоит оставить в специальных классах, которые контролируют время жизни объектов (в данном случае им вполне мог бы быть std::string, или что-то более общее типа boost::shared_array) |
