Здравствуйте, so5team, Вы писали:

S>Здравствуйте, lpd, Вы писали:

lpd>>Отличие только в том, что с использованием полиморфизма для result_successful_t и result_failure_t нужно будет добавить один базовый класс: result_t. Мне такой путь нравится больше шаблонов, хотя похоже, что это вопрос предпочтений.

S>Ну так напишите хотя бы приблизительный код. Сразу станет видно и его объем, и его надежность, и его понятность.

Писать код чтобы продемонстрировать полиморфизм, и его отличия от шаблонов? Открой любую книжку по C++ начала 200х. Сферический обработчик reply_t интереса не представляет, т.к. все зависит от деталей использование этих объектов.

S>>>И передавать их как? Через unique_ptr?
lpd>>Умные указатели я считаю только усложняющими управление памятью, хотя это оффтоп. Передавать просто через указатель "result_t *" — это самое простое.

S>Т.е. мы создаем result в динамической памяти? Дергаем хип и создаем лишнюю косвенность там, где можно было обойтись передачей/перемещением значения.

Ну все, фанатика move-семантики я переубедить не берусь. Все-таки подумай о том, что из использования C++ в требовательных к ресурсам проектах не значит, что любая операция в программе на C++ должна быть обязательно соптимизирована move-семантикой. А для тех очень редких операции, которые все-таки нужно оптимизировать, можно сделать пул объектов.

S>А потом, что вообще прекрасно, отдаем кому-то владеющий голый указатель в надежде на то, что кто-то когда-то его удалит?
S>Етить-колотить, казалось, что в мире C++ подобные взгляды на управление памятью уже в дикой природе не встречаются, только в каких-то особых замкнутых заповедниках. А поди ж ты.

В каждом конкретном случае такую проблему можно решить без умных указателей — вариантов решений много, включая подсчет ссылок. Хотя от полноценного GC польза была бы.