Templates - C/C++

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

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

Вообще тут проблема не в шаблонах и даже не С++, проблема в страсти многих программистов к абстракции и обобщению, в желании решить более обобщенную задачу чем требуется. Так бало с ООП, когда народ часто на пустом месте городил разветвленную 10-уровневую иерархию классов. Так было с паттернами, когда в код засовывали паттерны, просто потому, что недавно прочитали книгу по паттернам, и круто было бы где-нибудь какой-нибудь паттерн применить.

Шаблоны, обладают большой мощью и дают программисту огромное поле для обобщения и параметризации. И неокрепшие умы, повторяя мантру про избавление от copy/paste и повторное использование кода, начинают обобщать и параметризовать все, что можно и нельзя, просто потому-что могут. Крутой профессионал, как раз тот, кто может найти места, где нужно обобщать и параметризовывать, а где copy/paste нескольких строчек будет самым лучщим и простым решением.

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

Q>Весь Boost и Stl, очевидно, к удобству чтения и поддержки не имеют никакого отношения. Достаточно заглянуть в их исходники, что там скрыто за более или менее причёсанным фасадом.

О чём и говорю, почему разрабы gnu stl и boost не использовали навыки "написания чтоб понятно бУло" и навыки "неиспользования шаблонов"? И не надо что там иначе нельзя было. В либах Boost, которых просматривал, имеется куча мест, где можно было бы обойтись без шаблонов. Там всё на шаблонах по ряду причин. Читабельность кода авторов не волнует, так как знают, что плюсовики их уровня поймут код без проблем, а всякие квалифицированные умеющие неписать на шаблонах пусть идут лесом.

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

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

Ты путаешь такие активности как использование библиотеки и изменения её внутренностей. Авторы Буста жертвовали удобством второй активности ради удобства первой. «Плюсовикам их уровня» точно так же гораздо тяжелее понимать шаблонный код, чем обычный.

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

где copy/paste нескольких строчек будет самым лучщим и простым решением.

Ну, этот тред не про копипасту пары строчек, а про расписывание систем с введением обобщёний и без

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

S>Заметил, что у большинства практикующих C++ достаточно негативное отношение к шаблонам в CPP.

Хорошо бы пруфов. И про негативное. И, в особенности, про большинство.

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

Ну вот, схематически из совсем свежего:

struct successful_result_t { ... };
struct failed_result_t { ... };

struct reply_t {
  request_id_t id_;
  worker_id_t worker_;
  std::variant<successful_result_t, failed_result_t> 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)}
  {}
};

Позволяет использовать один и тот же конструктор и для

return reply_t{id, self, successful_result_t{...}};

и для

return reply_t{id, self, failed_result_t{...}};

И останется таковым даже если список результатов расширится, например, когда добавятся overloaded_result_t, postponed_result_t и пр. Не говоря уже о том, что сам по себе std::variant и средства работы с ним -- это сплошная шаблонная магия.

Вы вместе с вашими матерыми C++ разработчиками вместо этого предлагаете что?

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

S>Вы вместе с вашими матерыми C++ разработчиками вместо этого предлагаете что?

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

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

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

S> где copy/paste нескольких строчек будет самым лучщим и простым решением.

S>Ну, этот тред не про копипасту пары строчек, а про расписывание систем с введением обобщёний и без

Как правило на практике аццкие иерархии классов, шаблонов, стратегий, или еще чего-то там, как раз возникают когда народ пытается любой ценой избавится от каждой копипасты под лозунгом "любое дублирование кода — абсолютное зло!".

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

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

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

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

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

S>Ну вот, схематически из совсем свежего:
S>

struct successful_result_t { ... };
S>struct failed_result_t { ... };

S>struct reply_t {
S>  request_id_t id_;
S>  worker_id_t worker_;
S>  std::variant<successful_result_t, failed_result_t> result_;

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

S>Позволяет использовать один и тот же конструктор и для
S>

return reply_t{id, self, successful_result_t{...}};

S>и для
S>

return reply_t{id, self, failed_result_t{...}};

по твоему это активное применение шаблонов? :D

S>И останется таковым даже если список результатов расширится, например, когда добавятся overloaded_result_t, postponed_result_t и пр. Не говоря уже о том, что сам по себе std::variant и средства работы с ним -- это сплошная шаблонная магия.

если добавится overloaded_result тебе прийдется добавить его в variant, т.е. поменять свой класс reply_t, если бы твой к-тор сразу принимал variant то не потребовался бы шаблон и поменять список ответов, которые может принимать reply_t можно было бы в одном месте, там где определен тип этого std::variant, можно было бы вынести реализацию в cpp

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

CK>по твоему это активное применение шаблонов? :D

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

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

S>Ну вот, схематически из совсем свежего:
S>

struct successful_result_t { ... };
S>struct failed_result_t { ... };

S>struct reply_t {
S>  request_id_t id_;
S>  worker_id_t worker_;
S>  std::variant<successful_result_t, failed_result_t> result_;

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

S>Позволяет использовать один и тот же конструктор и для
S>

return reply_t{id, self, successful_result_t{...}};

S>и для
S>

return reply_t{id, self, failed_result_t{...}};

S>И останется таковым даже если список результатов расширится, например, когда добавятся overloaded_result_t, postponed_result_t и пр. Не говоря уже о том, что сам по себе std::variant и средства работы с ним -- это сплошная шаблонная магия.

S>Вы вместе с вашими матерыми C++ разработчиками вместо этого предлагаете что?

struct result_t
{
   bool successful ;
   ...
}

Не надо сочинять сущности без необходимости.
За это раньше жгли на костре.

Или даже так:

struct result_t { ... };

// в случае ошибки
throw -1 ; // тогда тебе просто не нужны данные failed_result_t

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

A>// в случае ошибки
A>throw -1 ; // тогда тебе просто не нужны данные failed_result_t
A>[/code]
A>

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

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

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

A>>// в случае ошибки
A>>throw -1 ; // тогда тебе просто не нужны данные failed_result_t
A>>[/code]
A>>

K>Сомневаюсь что сработает. Очевидно, что реализация на кодах возврата тут делается чтобы избежать проблем с исключениями в многопоточной среде.

Ну это я прикололся, сам понимаешь (по -1 вместо нормальной структуры ошибки).

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

K>Очевидно, что реализация на кодах возврата тут делается чтобы избежать проблем с исключениями в многопоточной среде.

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

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

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

lpd>Можно привести большой список того, что нужно уметь квалифицированному программисту, и в нем будет множество гораздо более важных вещей, чем шаблоны или C++17.

IMHO, cтранная точка зрения. Но твоё право — продолжать придерживаться ли её, или же прозреть...

lpd>Как раз логика 'лучший программист лучше знает язык программирования' звучит несколько сферично. А на практике практикующий программист C++ получит больше от изучения баз данных, устройства ОС и электроники...
В наше время есть понятие: разделение труда...

lpd>...когда он это изучит, для проекта будет важнее архитектура кода, который он пишет, чем использование сложных шаблонов или других фич C++17.
Фичи языка — это твои друзья, а НЕ враги!
Кстати, открою тебе маленький секрет — применение конструкции if constexpr из набора C++17 —
позволяет работать с шаблонами удобнее, чем раньше!!!
Вот простой пример:

template <typename C>
void print (const C &c)
{
    if constexpr (std::is_same_v<C, std::vector<int>>) {
        cout << "vector<int>: ";
    }

    if constexpr (std::is_same_v<C, std::list<int>>) {
        cout << "list<int>:   ";
    }

    if constexpr (std::is_same_v<C, std::deque<int>>) {
        cout << "deque<int>:  ";
    }

    for (auto i : c)
    {
        cout << i << ", ";
    }
    cout << '\n';
}

Архитектура кода — только выигрывает от применения современных возможностей языков программирования.
Так, применение приведенного выше метода, позволит тебе забыть о трудно-понимаемом SFINAE

lpd>Для программиста C++ главное вовсе не C++.
Хорошо, перефразирую твоё выражение так:
— Для хирурга — главное вовсе не умение оперировать.

...а теперь представь, что ты пациент именно этого врача...

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

K>Всё наооборот. Если плюсовик не умеет использовать шаблоны, то он неквалифицирован.

И если не умеет использовать и если не умеет не использовать и даже если не умеет отличать случаи, когда надо использовать от случае, когда не надо

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

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

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

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

S>Вы вместе с вашими матерыми C++ разработчиками вместо этого предлагаете что?

Это, кстати, хорошее упражнение. Представить, что шаблонов нет, или что свои нельзя писать и подумать, как написать тоже самое без шаблонов.
Потом представить, что полиморфизм на уровне языка тоже не поддерживается, и придумать решение в стиле "Си с классами", ну а потом из трёх выбрать лучшее.

Попробуешь сам?

	От:	smeeld
	Дата:	04.07.18 08:56
	Оценка:

От:	Qbit86	https://twitter.com/qbit86
Дата:	04.07.18 09:06
Оценка:	+1

	От:	ksandro
	Дата:	04.07.18 09:15
	Оценка:	+4

	От:	smeeld
	Дата:	04.07.18 09:19
	Оценка:

От:	Qbit86	https://twitter.com/qbit86
Дата:	04.07.18 09:32
Оценка:	+3

От:	so5team	https://stiffstream.com
Дата:	04.07.18 11:46
Оценка:	+2

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	04.07.18 13:04
Оценка: