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

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

S>В том-то и дело, что там, где не важно потребление ресурсов, спокойно пишут на Java/Scala/Kotlin/Ceylon, C#/F#/VisualBasic, Python, Ruby и даже, как говорят, на Haskell-е. Место для C++ осталось там, где важно иметь контроль за происходящим.

Я сторонник того, чтобы оптимизировать алгоритм, а код оставлять максимально простым и понятным. Для оптимизации все равно union и ассемблер сильнее, чем шаблоны и компилятор.

lpd>>В твоем примере можно просто reply_success_t и reply_failure_t унаследовать от reply_t, и этого достаточно для реализации любой логики.

S>Во-первых, *_resul_t специально отделены от reply_t. Т.к. там, где получается *_result_t, никто ничего не знает о reply_t.
Я имел ввиду либо базовый result_t, либо базовый reply_t — не обязательно оба вместе.
S>Во-вторых, логика будет усложнена за счет того, что придется ловить не один reply, а два разных (а потом, возможно и больше).
Отличие только в том, что с использованием полиморфизма для result_successful_t и result_failure_t нужно будет добавить один базовый класс: result_t. Мне такой путь нравится больше шаблонов, хотя похоже, что это вопрос предпочтений.
Для удобства можно добавить в result_t поле enum с кодом возврата.

lpd>>Либо result_success_t и result_failure_t унаследовать от result_t.

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

S>C union-ом все становится интереснее как только туда помещаются данные с нетривиальными деструкторами. И тогда сразу же возникает вопрос: чем это лучше std::variant?
reply_t и result_t обычно простые классы. У тебя есть указатель на result_failure_t. В result_failure_t определен деструктор. Не вижу сложностей.

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

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

S>В том-то и дело, что там, где не важно потребление ресурсов, спокойно пишут на Java/Scala/Kotlin/Ceylon, C#/F#/VisualBasic, Python, Ruby и даже, как говорят, на Haskell-е. Место для C++ осталось там, где важно иметь контроль за происходящим.

Я сторонник того, чтобы оптимизировать алгоритм, а код оставлять максимально простым и понятным. Для оптимизации все равно union и ассемблер сильнее, чем шаблоны и компилятор.

lpd>>В твоем примере можно просто reply_success_t и reply_failure_t унаследовать от reply_t, и этого достаточно для реализации любой логики.

S>Во-первых, *_resul_t специально отделены от reply_t. Т.к. там, где получается *_result_t, никто ничего не знает о reply_t.
Я имел ввиду либо базовый result_t, либо базовый reply_t — не обязательно оба вместе.
S>Во-вторых, логика будет усложнена за счет того, что придется ловить не один reply, а два разных (а потом, возможно и больше).
Отличие только в том, что с использованием полиморфизма для result_successful_t и result_failure_t нужно будет добавить один базовый класс: result_t. Мне такой путь нравится больше шаблонов, хотя похоже, что это вопрос предпочтений.
Для удобства можно добавить в result_t поле enum с кодом возврата.

lpd>>Либо result_success_t и result_failure_t унаследовать от result_t.

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

S>C union-ом все становится интереснее как только туда помещаются данные с нетривиальными деструкторами. И тогда сразу же возникает вопрос: чем это лучше std::variant?
reply_t и result_t обычно простые классы. У тебя есть указатель на result_t. В result_failure_t определен деструктор. Не вижу сложностей.