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

S>Для человека, который начинал с таким апломбом:

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

и

Это, кстати, хорошее упражнение...Попробуешь сам?

у вас оказалась на удивление тонкая душевная организация.

А ты с каким из двух утверждений не согласен?..
И при чём тут апломб? Это просто констатация фактов. Упражнение и правда хорошее.
IMHO, если человек вообще не может его выполнить он не особо квалифицированный программист...

Про код же, если говорить, то пока так и не понятно, зачем нужны result и reply?
В чём цель существования такого разделения?
Ещё интересно чем два разных result'a отличаются? И на каких аллокаторах аллокируются потроха? Или они все POD?

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

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

Например, почему бы не иметь базовый класс result, в котором иметь все нужные во всех случаях поля (то, что было в reply добавлено к варианту, и может что-то ещё), и выводить из него конкретные специфические результаты, ну и возвращать result* Или shared_ptr<result> или ещё какой владеющий указатель или, даже variant<result1, result2, result3,...>
Собственно этот вопрос про то, почему в качестве reply используется структура, а не вариант из результатов я тоже задавал, кстати
Мне конструкция с вариантом нравится меньше, так как повышается связность кода...

Вопрос в том, что бы обсуждать вопрос конструктивно. Возможно ответы на мои вопросы есть у тебя?..

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

S>Да сколько угодно, писать на Cи, а это будет именно Си, с классами, RAII и прочей шелухой, что в Си различными фреймворками реализуется в крупных проектах, вроде ядер, вообще просто. Проще чем на С++, что означает развитие системы абстракций в виде множества параметризованных обобщённых типов и взваимосвязей между ними. Короче, С++-это когда структурирование и обобщение в помощью шаблонов, если этого нет, то это Си с классами.

Во-первых, это спор о словах. Какая разница что как называется?
Во-вторых, в С++ без шаблонов ещё останется динамический полиморфизм, так что это будет "Си с классами, наследованием и виртуальными функции"...

Ну и в-третьих, в том-то и смысл, что программы хорошо писать не как покрасивее, или там поабстрактнее, а как быстрее понимать поддерживать и развивать код. Часто неудачно выбранные абстракции только загромождают код. Это по опыту чисто.

В том-то и смысл обсуждаемого упражнения. Придумать три ХОРОШИХ решения. В парадигме "С++ с шаблонами", "Си с ООП" и "Си с классами". Сравнить плюсы и минусы полученных решений, и выработать хорошее итоговое.

p. s. Чисто в порядке обмена опытом. В окружающей вас культуре разработки, на этапе проектирования кода, в проектах принято рассматривать возможные альтернативы и аргументировать выбор лучшей? Или проекты пишутся в стиле "делаем так! я так вижу!"?
Оба стиля имеют плюсы и минусы, можно так же обсуждать комбинированные стратегии.

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

E>Например, почему бы не иметь базовый класс result,

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

E>даже variant<result1, result2, result3,...>

Т.е. даже вы пришли к этому самому варианту.

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

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

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

E>Например, почему бы не иметь базовый класс result, в котором иметь все нужные во всех случаях поля (то, что было в reply добавлено к варианту, и может что-то ещё), и выводить из него конкретные специфические результаты, ну и возвращать result* Или shared_ptr<result> или ещё какой владеющий указатель или, даже variant<result1, result2, result3,...>
E>Собственно этот вопрос про то, почему в качестве reply используется структура, а не вариант из результатов я тоже задавал, кстати

в reply как раз и хранится вариант из результатов. или тебе не нравится что там кроме результата еще что-то хранится?

E>Мне конструкция с вариантом нравится меньше, так как повышается связность кода...

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

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

E>А ты с каким из двух утверждений не согласен?..

С обоими.

E>И при чём тут апломб? Это просто констатация фактов.

При том, что это апломб, а не констатация фактов.

E>IMHO, если человек вообще не может его выполнить он не особо квалифицированный программист...

Если вы думаете, что причина только в том, что "не может" и готовы давать оценки про "не особо квалифицированный", то разумно спросить: а вы-то сами кто? И, если совсем коротко, сколько в сантиметрах?

E>Про код же, если говорить, то пока так и не понятно, зачем нужны result и reply?

Тему перечитайте. Result -- это результат трансформации данных, не привязанный к тому, откуда эти данные пришли и кому их нужно отдать. А reply -- это result, который уже привязан к этой информации.

E>В чём цель существования такого разделения?

Так нужно было.

E>Ещё интересно чем два разных result'a отличаются?

В них разная информация, ваш К.О.

E>И на каких аллокаторах аллокируются потроха?

Штатных.

E>Или они все POD?

Не POD.

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

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

Так чтобы сравнивать, надо понимать как определены result'ы...


E>>даже variant<result1, result2, result3,...>

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

Но вариант — одна и рассматриваемых альтернатив. Я всё равно так и не понял, в чём цель (Зачем) разделения на reply и result.
Лично мне уже это место очень непонятное. Из какой функции что возвращать?
Вот вызываю я операцию Раз-Два. Она что вернёт? Успешный result, неуспешый result, какой-то комбинированный тип?
Я так понимаю, что речь идёт об обработке отказов на кодах возврата, а не на исключениях. Если это так, то по идее нужен какой-то универсальный тип результата, который вернут и при провале и при успехе и по которому можно будет понять, что вернули.
А иногда, мы этот результат хотим прокинуть между нитями. Тогда мы делаем какую-то функций врапер, которая зовёт обычную, заворачивает её result в reply и пересылает в другую нить.
А зачем такое разделение? Почему бы всем функциям не быть сразу же и враперами? С какой целью введён другой слой?
Такая примерно архитектура, или какая? Почему я должен за тебя придумывать контекст?

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

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

Q>Ты путаешь такие активности как использование библиотеки и изменения её внутренностей.

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

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

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

Не знаю как у других, но сам везде встречал обязательное требование от прибывшего на проект разраба как можно быстрее въехать в код, каким бы он сложным не был, и нигде не втречал требование к разрабам писать кода "как можно проще, чтоб джуны и глупцы поняли". Второго требование не встречал по одной простой причине-глупцов и джунов на проекты не брали, а матёрым плюсовикам разобраться в чужом коде, каким бы он запутанным или обобщённым параметризацией ни являлся, если что и помешает то только лень, и ничего более, это не так уж и сложно как многим здешним хейтерам шаблонов кажется. Это тот же С++, а не какая-то неведомая инопланетная лингва, проблемы с въезжанием в код могут быть только у джунов, глупцов и лентяев.

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

S>нигде не втречал требование к разрабам писать кода "как можно проще, чтоб джуны и глупцы поняли". Второго требование не встречал по одной простой причине-глупцов и джунов на проекты не брали

:) Тут за примером мне далеко идти не придётся — Google C++ Style Guide:

Avoid complicated template programming.

The techniques used in template metaprogramming are often obscure to anyone but language experts. Code that uses templates in complicated ways is often unreadable, and is hard to debug or maintain.

Template metaprogramming often leads to extremely poor compiler time error messages: even if an interface is simple, the complicated implementation details become visible when the user does something wrong.

Template metaprogramming interferes with large scale refactoring by making the job of refactoring tools harder. First, the template code is expanded in multiple contexts, and it's hard to verify that the transformation makes sense in all of them. Second, some refactoring tools work with an AST that only represents the structure of the code after template expansion. It can be difficult to automatically work back to the original source construct that needs to be rewritten.

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

S>каким бы он запутанным или обобщённым параметризацией ни являлся, если что и помешает то только лень

...И отсутствия x20 времени на разбор всех этих «typename _Meta_quote_helper_<void, _Fn, _Types...>::type», на которое согласились бы менеджеры. Вместо того, чтобы пилить конкретные фичи для пользователей, «разработчик» чешет своё самолюбие, осиливая «typename _Meta_repeat_n_c_<_Ty, make_index_sequence<_Count>, _Continue>::type», убеждая всех вокруг, что это нормально и несложно.

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

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

E>Так чтобы сравнивать, надо понимать как определены result'ы...

Не надо. Был показан простой код. В нем использовался простой фокус с шаблонами, который позволил написать вот так:

  template<typename Actual_Result>
  reply_t(request_id_t id, worker_id_t worker, Actual_Result && result)
    : id_{std::move(id)}, worker_{std::move(worker)}
    , result_{std::forward<Actual_Result>(result)}
  {}

а не вот так:

  reply_t(request_id_t id, worker_id_t worker, successful_result_t result)
    : id_{std::move(id)}, worker_{std::move(worker)}
    , result_{std::move(result)}
  {}
  reply_t(request_id_t id, worker_id_t worker, failed_result_t result)
    : id_{std::move(id)}, worker_{std::move(worker)}
    , result_{std::move(result)}
  {}

Но это же слишком просто для столь умудренных форумчан. Давайте развернем дискуссию о том, а уместно ли вообще применять std::variant? А подумал ли автор о том, что и successful_result_t, и failed_result_t можно обеденить? А может быть автор не подумал о том, что можно вообще без этих result-ов обойтись и все сразу запихнуть в reply? Да и с чего вообще автор решил, что ему нужны result-ы и reply-у?

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

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

Вот теперь, если вы настаиваете на своей высокой квалификации, можете поупражняться в альтернативных подходах к проблеме. А остальные посмотрят, какой подход лаконичнее, проще и т.д.

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

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

Q> Тут за примером мне далеко идти не придётся 

У гугеля тысячи проектов и столько же команд. Та вывеска вообще ни о чём не говорит. Общался с некоторыми комитерами linux kernel и openbsd, работающими в гугеле, на С++ проектах, говорили что там весь код из многоуровых шаблонов, пишут точно в стиле либ из boost.

Встречал также интервью одного openbsd-ишника из РФ, тот отызвался уже о том, как пишут на С++ в Яндексе, то же про шаблоны говорил:

А: Про программистов на C++ ходит такой еще слух (нам, сторонним людям, очень интересно, что ты скажешь о слухах, которые ходят о Яндексе), что у вас там сплошные шаблоны на шаблонах, и метапрограммирование на шаблонах, ехал шаблон через шаблон. Это правда, или это в другом отделе, или этого вообще нет?

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

А: Метапрограммированию, наверное?

АЮ: Ну, и это тоже, да.

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

S>Встречал также интервью одного openbsd-ишника из РФ, тот отызвался уже о том, как пишут на С++ в Яндексе, то же про шаблоны говорил:

«Но снаружи это не особо видно. То есть, один раз этот код написан... Использование шаблонов, как замена функциональному программированию, особо не приветствуется из-за сложности отладки.»

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

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

S>>Встречал также интервью одного openbsd-ишника из РФ, тот отызвался уже о том, как пишут на С++ в Яндексе, то же про шаблоны говорил:

Q>«Но снаружи это не особо видно. То есть, один раз этот код написан... Использование шаблонов, как замена функциональному программированию, особо не приветствуется из-за сложности отладки.»

И что? Либа-то написана, если иначе нельзя, то приходится возиться.

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

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

NB>в reply как раз и хранится вариант из результатов. или тебе не нравится что там кроме результата еще что-то хранится?
Мне не понятно, чем отличаются ответы и результаты концептуально...

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

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

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

S>С обоими.
S>При том, что это апломб, а не констатация фактов.

Очень содержательное и, главное, понятное сообщение (оба раза)
Кстати, почему ты думаешь, что упражнение не полезное?

E>>IMHO, если человек вообще не может его выполнить он не особо квалифицированный программист...
S>Если вы думаете, что причина только в том, что "не может"
Я прямо сказал, что думаю, что ты сможешь, если захочешь... Читать в школе программирования на С++ не учили что ли?

S>и готовы давать оценки про "не особо квалифицированный", то разумно спросить: а вы-то сами кто? И, если совсем коротко, сколько в сантиметрах?
Не бери в голову, всё равно не поместится

E>>Про код же, если говорить, то пока так и не понятно, зачем нужны result и reply?
S>Тему перечитайте. Result -- это результат трансформации данных, не привязанный к тому, откуда эти данные пришли и кому их нужно отдать. А reply -- это result, который уже привязан к этой информации.

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

E>>В чём цель существования такого разделения?
S>Так нужно было.
Понимаю. Рационализация у этого "нужно", хотя бы какая-то есть?



E>>Ещё интересно чем два разных result'a отличаются?
S>В них разная информация, ваш К.О.
Ну конкретно чем. Это результаты для любых операций? Если да, то интересно что такого хитрого обобщили. Или для каждой операции своя пара результатов?

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

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

как бы фраза

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

была сказана именно при обсуждении кода.

NB>>в reply как раз и хранится вариант из результатов. или тебе не нравится что там кроме результата еще что-то хранится?
E>Мне не понятно, чем отличаются ответы и результаты концептуально...

ну, очевидно что в ответе кроме результата хранится дополнительная информация.
можно ее засунуть в результат, но зачем она там, если к результату не относится,

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

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

как минимум отсутствием дополнительного оверхеда, связанного с умными указателями.

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

E>>Так чтобы сравнивать, надо понимать как определены result'ы...

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

Я же написал. Без больших причин я бы не разделял result и replay
Вся конструкция целиком была бы не нужна...

Но, возможно я не понимаю, как используются результаты. Я так понимаю, что обычно всё равно возвращается что-то вроде варианта из результатов. Так что зачем
1) не сделать его же и параметром конструктора ответа
2) вообще отказаться от ответов, как идеи я не понимаю.

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

И да, я не хочу подтверждать или опровергать чью бы то ни было квалификацию. Я обсуждаю стили кодирования, а не людей.

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

S>то разумно спросить: а вы-то сами кто?

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