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

S>И читать нужно всю тему, т.к. нет никакого резона пересказывать персонально то, что уже было рассказано выше. Но, если вы внимательно читать обсуждения не способны, то пусть будет такой контекст: один рабочий поток-менеджер берет откуда-то некий request и выбирает рабочий поток-обработчик, которому request будет передан. Рабочий поток-обработчик обрабатывает данные из request и отдает назад reply для того, чтобы потом-менеджер смог ответить на исходный request. В reply должен быть актуальный результат обработки данных. Этот результат на данный момент, может быть либо успешным (и тогда в нем будут обработанные данные), либо неудачным (и тогда там будет что-то касающееся причины неудачи). Возможно, что этот список будет расширен в будущем. Важно лишь то, что поток-обработчик должен точно сообщить что получилось, а поток-менеджер должен разобраться с тем, что ему возвратили.

А откуда поток обработчик, берёт тот или иной result, разных типов, что бы завернуть это в ответ и отправить в поток-менеджер?
Эта функция, которую на потоке-обработчике вызывают, она как устроена? Она ловит исключения с провальным результатом или получает как результат успешный? Или как-то ещё сделано?
Почему полиморфный (тип зависит от значения) replay нужен, а result -- нет?

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

E>Очень содержательное и, главное, понятное сообщение (оба раза)

В точности как у вас.

E>Кстати, почему ты думаешь, что упражнение не полезное?

Где говорилось, что оно не полезное? Только какой смысл заниматься этим упражнением в очередной раз нам, а не вам?

E>Это ответ на вопрос "почему?", а не "зачем?" Слово "зачем" подразумевает наличие осознанной цели...

Тему перечитайте.

E>Понимаю.

Не заметно.

E>Рационализация у этого "нужно", хотя бы какая-то есть?

Конечно.

E>Если да, то интересно что такого хитрого обобщили.

Блин, да вы пример исходный прочитайте внимательно. Там обобщен конструктор у reply_t. Хватит выдумывать воздушные замки.

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

E>Я же написал. Без больших причин я бы не разделял result и replay

Ну так напишите, как бы вы представили reply. Исходя из своих соображений о прекрасном.

E>Так что мой ответ такой. Весь этот код не нужен

Ну так и начинать нужно было именно с этого. А то "не контролируешь распространение шаблонов", "есть полезное упражнение". По взрослому нужно: код не нужен и точка.

E>А откуда поток обработчик, берёт тот или иной result, разных типов, что бы завернуть это в ответ и отправить в поток-менеджер?

Представьте себе такой схематический код:

void transformer::handle(channel & reply_ch, const request & req) {
  try {
    auto transformed_data = some_external_function(req.source_data(), req.transformation_params());
    ... // Что-то еще.
    reply_ch.send(reply_t{req.id(), self_id(), successful_result_t{..., std::move(transformed_data), ...});
  }
  catch(const exception & x) {
    ... // Что-то...
    reply_ch.send(reply_t{req.id(), self_id(), failed_result_t{..., x.what(), ...});
  }
}

Станет легче?

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

NB>как бы фраза
NB>

NB>Это всего лишь означает, что ты не умеешь контролировать их "расползание" по коду...

NB>была сказана именно при обсуждении кода.
Если шаблоны возникают в неожиданных для программиста местах, помимо его воли целей и планов, а потому, что "так получилось", то это и значит, что в той парадигме, в которой программист работает, не получается контролировать расползание шаблонов по коду...
Есть какая-то ещё интерпретация того факта, что шаблоны возникают помимо воли программистов?

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

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

E>Есть какая-то ещё интерпретация того факта, что шаблоны возникают помимо воли программистов?

а кто говорил что они возникают помимо воли программиста?
речь была про то что изначально они не планировались, потом система эволюционировала.
что в этом такого необычного.

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

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

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

S>Представьте себе такой схематический код:
S>

void transformer::handle(channel & reply_ch, const request & req) {
S>  try {
S>    auto transformed_data = some_external_function(req.source_data(), req.transformation_params());
S>    ... // Что-то еще.
S>    reply_ch.send(reply_t{req.id(), self_id(), successful_result_t{..., std::move(transformed_data), ...});
S>  }
S>  catch(const exception & x) {
S>    ... // Что-то...
S>    reply_ch.send(reply_t{req.id(), self_id(), failed_result_t{..., x.what(), ...});
S>  }
S>}

S>Станет легче?
Так стало понятнее, но не до конца, если честно.
1) failed_result_t и successful_result_t где-то, кроме этой конструкции используются? Если да, то как, если нет, то опять не понято зачем два уровня классов (reply и xxx_reult)
2) Таких трансформеров много? У них у всех общий successful_result_t и общий failed_result_t или у каждого свои?
3) transformed_data всегда одного типа (во всех трансформерах?)
4) чем отличаются точечки в successful_result_t{..., std::move(transformed_data), ...}) от точечек в failed_result_t{..., x.what(), ...})?
5) Зачем reply_t вообще явно написанные конструкторы? Почему он не простая структура?

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

NB>а кто говорил что они возникают помимо воли программиста?
NB>речь была про то что изначально они не планировались, потом система эволюционировала.

потом система эволюционировала

Дык это и есть помимо воли программиста

NB>что в этом такого необычного.
Дык проблемы и сложности — это вообще норма жизни

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

NB>а вот проделать обратное изначально спроектировав все на умных указателях будет труднее...
Почему? Чем вообще умный указатель на базу так сильно отличается от варианта из возможных наследников?
Только тем, что больше весит объект и на принимающей стороне должны знать все возможные варианты результатов...

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

E>Чем variant отличается от динамического полиморфизма? Тип объекта определяется его значением...

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

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

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

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

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

CK>Я очень часто встречал ситуации, когда тип параметризован, из-за этого код живет в *.h, любое его изменение приводит к перекомпиляции половины приложения, clang analyzer не кажет баги, в IDE не работает автодополнение. При этом всегда используется один и тот же параметр! На вопрос — а чО так, разработчик отвечает — а вдруг потом нужно будет? Преждевременная генерализация, это как преждевременная эякуляция, только хуже, т.к. за последнее не уволняют с работы.

Дык уневерсальный всемогутер -- самый мощный антипаттерн жеж

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

E>Так стало понятнее, но не до конца, если честно.
E>1) failed_result_t и successful_result_t где-то, кроме этой конструкции используются?

failed_result_t/successful_result_t описывают результат одной конкретной трансформации. Если трансформаций станет больше, то, возможно, появятся свои failed_result_t/successful_result_t для новых трансформаций. Или же эти будут переиспользованы. Это пока не ясно.

E>Если да, то как, если нет, то опять не понято зачем два уровня классов (reply и xxx_reult)

Это как разговор про T и std::vector<T>. Или даже T и std::unique_ptr<T>. Есть T сам по себе, важный с точки зрения прикладной логики, а есть контейнер для T нужный в каком-то случае. Вот reply -- это такой контейнер для result-а, который хранит result+еще что-то.

E>2) Таких трансформеров много? У них у всех общий successful_result_t и общий failed_result_t или у каждого свои?

Пока один. Что будет в будущем расписано выше.

E>4) чем отличаются точечки в successful_result_t{..., std::move(transformed_data), ...}) от точечек в failed_result_t{..., x.what(), ...})?

Разные наборы данных внутри. Разные наборы данных в конструкторе.

E>5) Зачем reply_t вообще явно написанные конструкторы? Почему он не простая структура?

Поскольку reply_t сам наследуется от еще одного базового типа.

Вообще, вот определение reply_t и сопутствующих типов (resize_result_t -- это reply_t и есть). Вот формирование reply. Сейчас там код разбит на две функции, начиналось все несколько по другому. И, кстати говоря, шаблонный конструктор позволил этого даже и не заметить. Вот обработка reply у менеджера. Можно обратить внимание, что отдельно обрабатывается одно поле из reply, и отдельно обрабатываются другие поля оттуда. Причем, в зависимости от result-а, обрабатываются по разному.

Код далеко не production-ready, это исследовательский прототип, который может поменяться в любую сторону.

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

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

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

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

по поводу юз кейсов ничего не могу сказать.

NB>>а вот проделать обратное изначально спроектировав все на умных указателях будет труднее...
E>Почему? Чем вообще умный указатель на базу так сильно отличается от варианта из возможных наследников?
E>Только тем, что больше весит объект и на принимающей стороне должны знать все возможные варианты результатов...

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

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

NB>и потом этот variant будет муваться в член класса. итого 2 мува.
А зачем reply_t вообще конструктор?

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

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

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

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

NB>>и потом этот variant будет муваться в член класса. итого 2 мува.
E>А зачем reply_t вообще конструктор?

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

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

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

На самом деле связанные, но взаимоисключающие. Т.е. они в принципе не могут существовать одновременно.

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

С возможностью контроля со стороны компилятора за обработкой всех вариантов (если применять std::visit).

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

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

S>С возможностью контроля со стороны компилятора за обработкой всех вариантов (если применять std::visit).

речь не про тебя, а про альфу

Автор: alpha21264
Дата: 05.07.18

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

V>Самым ужасающим будет (скорее всего в c++20 не войдет, позже) Reflection. По сравнению с ним — текущие "шаблоны" — просто детский лепет. Так что, "большинству практикующих C++" придется либо переключить негатив c "шаблонов" на более ужасные вещи, либо, если они уж и впрямь сильно практикуют — расширить, включив туда, кроме "шаблонов" — еще и эти новые страшилки

Reflection -- это прикольно, но зависит от того, как сделают.
Что касается шаблонов, то главная проблема С++ шаблонов -- это очень большой периметр зависимостей. Нет никакого формального контролируемого описания интерфейса шаблона, поэтому шаблонный код получается с очень сильно завышенной связностью.
Так что концепты, например, тоже могут улучшить ситуацию, а не ухудшить...

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

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

Q>Страшно, когда в обычном прикладном проекте появляется write-only код как из реализации этого std::variant. Если некто тащит такое в совместный с другими людьми проект просто потому, что может, и «хватит быть луддитами из девяностых» — это железобетонный признак профнепригодности.

Тут вот какая штука. Сложный шаблонный код еще вовсе не показатель, что такой код не оправдан или написан ради демонстрации собственных возможностей. Применение шаблонов вполне может быть оправдано, но сложность их реализации может быть вызвана недостаточными выразительными возможностями C++. Вообще или конкретно той версии, на которую приходилось ориентироваться. Скажем, написать безопасный по типам printf во времена C++98/03 для переменного количества параметров было той еще задачкой (емнип, без макросов она решалась разве что тоннами копипасты). В C++11 за счет появления variadic templates это стало проще. Но если еще добавить к такому printf требование проверки соответствия типов в compile-time, то и возможностей C++11, afaik, не хватит. Но в С++14/17 какие-то подвижки в этом направлении уже могут быть. И то, что требовало титанических усилий раньше, со временем становится проще.

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