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

_>Реализацией аналога полиморфизма виртуальных функций на шаблонах является скорее вот эта https://www.boost.org/doc/libs/1_67_0/doc/html/boost_typeerasure.html библиотека. А std::variant — это всё же шаблонный аналог union, а не реализация полиморфизма.

Ну тогда и shared_ptr<base_result_t> аналог union. Отличается, только стратегией аллокации памяти же?

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

E>Соответственно и программа сможет сделать что угодно произвольным способом. Добро пожаловать в страну творческой отладки

E>Удобно должно быть, в первую очередь, баги фиксить

Ещё со времён участия в проектах по разработке компонентов для solaris kernel, отлаживать привык трассировкой, поэтому в любую систему, которую случается развивать, закидываю мини аналог Dtrace собственного авторства. Мне общепринятые средства отладки без надобности, а используемый аналог Dtrace информативен в равной степени, независимо от того, расписан ли код на шаблонах или это Си.

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

_>>Реализацией аналога полиморфизма виртуальных функций на шаблонах является скорее вот эта https://www.boost.org/doc/libs/1_67_0/doc/html/boost_typeerasure.html библиотека. А std::variant — это всё же шаблонный аналог union, а не реализация полиморфизма.
E>Ну тогда и shared_ptr<base_result_t> аналог union. Отличается, только стратегией аллокации памяти же?

Нет, shared_ptr<base_result_t>, так же как и просто base_result_t* (не принципиально в данной дискуссии), так же как и boost::any из библиотеки по ссылке выше являются реализациями одной задачи (правда последняя реализация намного лучше остальных, т.к. boost::any позволяет объединять в себя типы не связанные иерархией наследования). Это задача бесконечного расширения обобщаемых типов. Ценой же этой возможности является дополнительных уровень косвенности (скрытый от программиста внутри реализации) при таком обобщённом обращение к конкретному классу.

А std::variant и union наоборот не позволяют бесконечно расширения обобщаемых типов — их список жёстко фиксируется на момент объявления нашего обобщённого типа и не может меняться без его переписывания. Зато при его использование никаких дополнительных уровней косвенности не возникает. Ну и плюс тут доступны не только функции-члены обобщаемых классов, но и переменные-члены.

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

NB>конкретно в этом примере может и не нужен, а вообще -- инкапсуляция и все такое.
Это же по сути структура?

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

S>Ещё со времён участия в проектах по разработке компонентов для solaris kernel, отлаживать привык трассировкой, поэтому в любую систему, которую случается развивать, закидываю мини аналог Dtrace собственного авторства. Мне общепринятые средства отладки без надобности, а используемый аналог Dtrace информативен в равной степени, независимо от того, расписан ли код на шаблонах или это Си.

В С++ много кода вызывается неявно...

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

NB>>конкретно в этом примере может и не нужен, а вообще -- инкапсуляция и все такое.
E>Это же по сути структура?

не понял вопроса.
если от в том, нужна ли для reply_t инкапсуляция, но вопрос не по адресу.

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

S>типа матёрый плюсовик всегда найдёт способ расписать без создания параметризованных типов,

Матёрый плюсовик понимает, когда лучше использовать шаблоны, а когда — лучше не использовать.

S>и вообще найдёт способ писать на C++ как можно проще

Код потом сопровождать надо будет. Поэтому — хороший разработчик на любом языке старается писать проще и не добавлять сложности без необходимости.

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

K>лет так под 25 назад плюсовые компиляторы плохо работали с шаблонами
K>это нанесло глубокую душевную травму программистам тех времен, и они шаблоны избегали

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

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

E>В С++ много кода вызывается неявно...

Штук из STL и libstdc++ (типа dynamic_cast) старюсь избегать, все утилитарные сущности, вроде std::map/vector свои (вернее, скопипащенные и перепиленные под нужды). Также не сторонник пихать сложную логику в конструкторы и деструкторы.

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

NB>>>ну а по сути, твое предложение сводится к реализации std::variant собственными силами.
E>>По сути он предложил взять простую структуру место трёх хитро взаимодействующих классов...

NB>по сути он предложил совершенно не связанные между собой классы поместить в одну кучу и предоставить пользователям самим разбираться, как эту кучу разгребать...

Ну ты пожалуйста всё читай.
Я же сказал, что по жизни в этой куче будет ровно один класс — класс успешного завершения.
Класс неуспешного завершения будет пустой. Поэтому в 99% случаев я могу обойтись одной кучей.

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

S>А ведь ряд бенефитов (например, безопасность по типам, контроль в compile-time) хочется получить уже сейчас. Ибо увеличение времени компиляции и сложность кода -- это, конечно, плохо. Но попадающие в продакшен баги из-за недостаточного контроля в compile-time могут быть куда дороже.

Ну есть, как минимум три альтернативных пути,
1) Вообще не пользоваться printf, а сделать как-то совсем по другому. Как в cout, например. Тем более, что в printf свои типы всё равно фиг выведешь нормально...
2) Написать ориентированный на эту задачу предтранслятор/испектор кода.
3) Забить

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

TB>Только чтоб считаться гуру, то помимо умения использования шаблонов нужно ещё умение неиспользования шаблонов.

А это со всем так, не только с шаблонами. Например, ударившись в ООП, забывают вообще про существование свободных функций и городят не пойми что, переусложняя код.

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

S>Заметил, что у большинства практикующих C++ достаточно негативное отношение к шаблонам в CPP. Речь идёт не о использовании std или boost, которые состоят из таковых процентов на 80, а о написании кода с активным применением параметризации функций и типов. Это многими считается чуть ли не признаком недостатка квалификации, типа матёрый плюсовик всегда найдёт способ расписать без создания параметризованных типов, и вообще найдёт способ писать на C++ как можно проще. Это вообще что такое?

Это просто называется твои выдумки.
Ты сам себе придумал, и теперь возмущаешься.
На практике просто есть разный код, разного назначения, есть библиотечный код с какими-то абстракциями, типа структур данных (например, деревья),
там шаблонный код уместен и нужен, а есть прикладной конкретный код, который связан, скажем, с программированием GUI, там шаблонный код
в общем не нужен, там всё вполне конкретное, и шаблоны могут только может использоваться.

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

MZ>Это просто называется твои выдумки.

Ничего не придумывал, почитайте этот тред или этот

Автор: chaotic-kotik
Дата: 08.07.18