Комментарии 28
Однако, к моему удивлению, при описании полиморфизма никто (или почти никто) не затрагивает тот факт, что помимо динамического полиморфизма в C++ имеется и достаточно мощная возможность использования его младшего брата – полиморфизма статического.
Наверное потому, что ни у кого не возникает желания придумывать собственную терминологию.
Шаблоны - одно. Таблица виртуальных функций - другое. И не надо, pls, придумывать им свои термины "динамический/статический полиморфизм" и пр.
Тем более, что использование слова "динамический" к результату компиляции (ассемблерный код процессора реализующий выбор виртуальной" функции) и противопоставление это шаблонам (то же ассемблерный код процессора) весьма спорно.
Так, использование шаблонов позволяет немного сэкономить время при выполнении программы
может все же при разработке программы?
Шаблоны в С++ это "ой. макросами как то не очень. Давайте придумаем новый инструмент".
С++ стар и полон концептуальных заплат (надо поддержать совместимость).
Шаблоны в С++ это
А где это лучше, и чем?
Появление и развитие C++ от C наблюдал своими глазами (и лет 15 на C/C++ активно писал с 1990).
Стандарты и "куда идем" определяются конкретными людьми и группами и модными на данный момент подходами. Появление STL либ и обсуждение этой темы то же помню (быть или не быть). И код где STL пихался куда только можно (ну модно же. "современная" концепция шаблонов жж).
Особого смысла спорить и пережевывать это не вижу. "На вкус и цвет все фломастеры разные".
И что получилось - то получилось в С++. Смысл спорить с зафиксированной данностью.
Я в курсе всего этого. Вы так рассуждаете, как будто это чем-то плохо. Шаблоны выполняют свою задачу, что ещё надо? Хотелось бы лучше, как в каких-то других языках? Вот я и пытаюсь понять, в каких, и чего не хватает.
И код где STL пихался куда только можно
А с STL-то что не так? Просто не нравится? Кому не нравится, пишут велосипеды или пользуются другими библиотеками. Это всё тоже зафиксированная данность.
Под "код пихался куда только можно" я имею в виду чужие исходники (прикладные не либы) где определяется STL класс и используется только с одном типом и в принципе (100%) не предполагается использовать с другим типом. И этим грешили многие.
Просто потому что (предполагаю) человек(и) изучал STL и впихнул его "потому что модно".
Ничего против шаблонов в хорошо продуманном коде не имею.
Просто потому что (предполагаю) человек(и) изучал STL и впихнул его "потому что модно".
Честно, не понял, о чем Вы. Пример кода можете привести?
что то типа h файл в котором
template<class T>
class BlaBla {
..
А потом использование этого класса/шаблона с только одним типом. Потому что в принципе не предполагалось других типов.
На вопрос "а зачем делать через шаблон?" ответ "ну... так красивее и модно" (давно было).
Теперь понятно.
Я и другое видел: есть базовый класс с виртуальной функцией. От него наследован производный класс, в нём своя реализация этой виртуальной функции. В программе используется только один экземпляр производного класса, больше классов нет. Зачем это всё, никто сказать не может.
ну это то же самое "не правильно спроектировано" или "Изучил тему чего то и теперь везде это пихаю".
ну или "авось пригодится" но.. в 99% случаях не пригождается
Как мне кажется, такие вещи закладываются с целью - иметь запас на вырост. Т.е. да, сейчас в данной реализации используется только один экземпляр, но возможно, потом производных классов будет больше и виртуальность пригодится.
Так а при чем здесь STL вообще?
Это просто иллюстрация к фразе "код пихался куда только можно"
У вас не получилось донести свою мысль (если таковая вообще была).
Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.
Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.
Я вас чем то персонально задел, обидел?
Есть люди, которых можно назвать "токсичным" и "душным".
Вы додумываете за другого что то, а потом на ровном месте пытаетесь оскорбить используя придуманные Вами же мысли и недосказанности собеседника.
Даже не буду пытаться дискутировать и опровергать придуманные Вами за меня мои мысли. Это путь в никуда.
Уже после того как написал, пробежался бегло по вашим комментам в других темах.
Бр.. не дай боже с таким человеком вместе работать.
Что то у Вас в жизни не так..
Вы пришли на публичную площадку и высказались так, что вас оказалось непросто понять. Например (лишнее поскипано):
я имею в виду чужие исходники (прикладные не либы) где определяется STL класс...
Что такое "STL класс"?
STL -- это standard template library. Как кто-то может взять и определить класс из standard template library?
У вас пытаются выяснить что вы имеете в виду, вы не можете ничего внятного ответить. Выяснить же пытаются для того, чтобы понять что вы сказали.
Если вам пофиг на то, что ваши же слова пытаются воспринять всерьез, то OK.
Доморрщенный std:: shared_ptr! Мне такое попадалось. Это они так на Си++98 с 11го переходили.
И вот прямо в пространстве имен std::?
Что-то мне подсказывает, что это вряд ли была распространенная практика.
И еще больше подозрений, что внезапно замолчавший @mmMike имел в виду именно такие случаи.
А потом использование этого класса/шаблона с только одним типом. Потому что в принципе не предполагалось других типов.
очень часто бывает намного хуже: написали и базовый класс или шаблон, и несколько наследников, но наследники отличаются только названиями классов, а в реализациях сплошной копи-паст с разными константами, для которых автор не догадался где и как определить переменную-поле класса, точно также как в примерах в этой статье:
return this->worth / 500;
return this->worth / 200;
return this->worth / 1000;
вместо того чтобы завести параметр в исходном классе и инициализировать его при создании объекта, мы нагородили модный полиморфизм! Круто же!
Это очень показательная статья о том как превратить CPP в настоящий Copy Past Programming.
Привет, коллега. Я вот тоже активно использовал C++ ещё со времён второго Cfront, но то, куда двинулся язык после внедрения шаблонов, меня сначала изрядно тормознуло, а позже и вовсе отвратило от него. Нахожу весьма забавным и показательным тот факт, что А. Степанов глубоко разочарован тем, во что эволюционировал C++ с тех пор, как он создал STL. И немалую роль в этом всём сыграл создатель C++, который из своего тщеславия соглашался практически на всё, что предлагали члены WG (а тут важно понимать, что немалая их часть — вовсе не самостоятельные люди, а лоббисты разных групп, хотелки которых нередко конфликтуют). Ох, не зря Томпсон всю дорогу в AT&T чморил и C++, и самого Страуструпа, чем регулярно вызывал у последнего полыхание пятой точки.
Терминология (статический/динамический полиморфизм и т.д.) абсолютно верная. Просто нужно воспринимать ее не как терминологию конкнретного языка, а как терминологию программирования в целом.
И не надо, pls, придумывать им свои термины "динамический/статический полиморфизм" и пр
Это широко распространненная терминология. Просто как пример:
Джосаттис Николаи М., Грегор Дуглас, Вандевурд Дэвид. Шаблоны C++. Справочник разработчика. Второе издание. Часть 3, Глава 22: Статический и Динамический полиморфизм. (стр. 581)
И это еще до C++20 и концептов концептов.
может все же при разработке программы?
Подозреваю, что именно при выполнении, так как не происхоит косвенных вызовов по vtable.
Шаблоны в С++ это "ой. макросами как то не очень. Давайте придумаем новый инструмент".
Это не так даже в первом приближении.
ИМХО, статический полиморфизм хорошая альтернатива динамическому в очень многих ситуациях.
На самом деле термин давно есть, только, как я помню, это принято называть не "статический", а "параметрический".
Однако, к моему удивлению, при описании полиморфизма никто (или почти никто) не затрагивает тот факт, что помимо динамического полиморфизма в C++ имеется и достаточно мощная возможность использования его младшего брата – полиморфизма статического
Серьезно. Вы смотрели видео с cppcon? А про CRTP слышали? Люди даже вариации vtable пишут...
Надо отметить что Си++ позволяет реализовать динамическое полиморфное присвоение и копирование/перемещение, но для этого нужно постараться и нужны веские причины. Чаще просто создается публичный интерфейс для такой операции (как copyFrom в Google protobuf?)
Если уж говорить за "полиморфизм времени компиляции", то это, ИМХО, как-то так должно выглядеть:
#include <variant>
struct A
{
void Foo();
void Foo1();
};
struct B
{
void Foo();
void Foo1();
};
struct C{
void Foo1();
};
struct Common :
public std::variant<A,B,C>
{
private:
struct True {};
struct False{};
template<typename Type>
struct TestMethod_Foo
{
private:
static False detect(...);
template<typename U>
static decltype(std::declval<U>().Foo()) detect(U&&);
public:
static constexpr bool value = !std::is_same_v< False, decltype(detect(std::declval<Type>()))>;
};
public:
using std::variant<A, B, C>::variant;
void Foo()
{
std::visit([](auto &&arg) {
using Type = std::decay_t<decltype(arg)>;
if constexpr (TestMethod_Foo<Type>::value)
arg.Foo();
else
// реализация по умочанию
}, *this);
}
void Foo1()
{
std::visit([](auto &&arg) { arg.Foo1(); }, *this); // аналог чисто виртуальной функции
}
};Выглядит конечно страшно, но, в результате, имеем поведение, похожее на динамический полиморфизм без таблицы виртуальных функций. Из минусов, стандартный размен: процессорное время на потребляемую память.
Статический и динамический полиморфизм в C++