языки программирования

[Medium-rare]

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

Когда ранее? В C++ templates существуют не так долго, как вирутальные методы?

[Мальчик-Одуванчик]

до 2003 года многие компиляторы поддерживали параметризацию достаточно криво
Это с технической точки зрения.
Реально же до Александреску (2001 год) на метопрограммировании никто особенно внимания не акцентировал
Более популярным было обьектно-ориентированное программирование в стиле Буча и банды заточенное под
динамический полиморфизм.

[crypto5]

до 2003 года многие компиляторы поддерживали параметризацию достаточно криво
Это с технической точки зрения.
Реально же до Александреску (2001 год) на метопрограммировании никто особенно внимания не акцентировал
Более популярным было обьектно-ориентированное программирование в стиле Буча и банды заточенное под
динамический полиморфизм.

Так а несложно выложить простенький код с примером применения специализации по отношению к шаблону strategy? Этп ведь наверное не больше 10 строк кода?

[dotcom]

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

Для запутаного синтаксиса нужно тратить больше тактов мозга на чтение чужого кода?

В идеализированном мире после преодоления порога, все остальное должно пониматься налету. А "запутанный" синтаксис можно сгенерировать на любом языке. Было бы желание.

[Medium-rare]

Ну, если Александреску не акцентировал, но в MFC уже тимплейты (CArray, CMap, ...) были аж до того, как примеры STL мало-мальски компиллировались, тады я... всё равно не верю!

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

[avitya]

Контейнеры в МФЦ это ад и треш До сих пор содрогаюсь от CMapStringToString и прочих.

[Мальчик-Одуванчик]

Так а несложно выложить простенький код с примером применения специализации по отношению к шаблону strategy? Этп ведь наверное не больше 10 строк кода?

typedef char (&MyStrategy)[1];
template <typename > class Strategy {};
template <> class Strategy <MyStrategy>{
public:
void use() { cout << "MyStrategy" << endl;}
};
template <typename T> class Context {
T strategy_;
public:
void usestrategy() {strategy_.use();}
};

[Palych]

Реальная проблема C++ в том, что он слишком низкоуровневый с запутанным синтаксисом.

А по мне так главная проблема - последствия низкоуровневости, когда базовые вещи (управление памятью например) можно сделать 1024 разными способами.
Это создаёт сложности в интеграции.
Например - решили использовать DOM в проекте.
В Java: Погуглил "Java DOM Implementation", пошарил в JavaDoc, выбрал что удобнее (Dom4j, JDom, etc.) включил jar - поехали.
В C++: погуглил, вроде что-то нашёл, да принципы управления памятью несовместимы с остальным проектом. Пишем адаптер. Потом отлаживаем его, особенно в многопоточной среде. Потом оказывается что этот доморощенный адаптер не работает в определённых условиях... А так хотелось просто использовать DOM, а не рефлексировать...
При этом в Java есть куча стандартизированных de jure или de facto интерфейсов, в которых реализации можно подменять не затрагивая кода.

[Medium-rare]

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

Так а несложно выложить простенький код с примером применения специализации по отношению к шаблону strategy? Этп ведь наверное не больше 10 строк кода?

Code: Select all

typedef char (&MyStrategy)[1];
template <typename > class Strategy {};
template <> class Strategy <MyStrategy>{
  public:
    void use() { cout << "MyStrategy" << endl;}
};
template <typename T> class Context {
    T strategy_;
    public:
     void usestrategy() {strategy_.use();}
}

[Мальчик-Одуванчик]

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

смысл в том чтобы настроить поведение в зависимости от тех или иных условий.
а вот когда - зависит от самой задачи и собственно определяет тип полиморфизма.
У того же Александреску полно примеров когда это лучше делать статически. Взять, хотябы его пример с оболочкой над указателем (smart pointer), где несколько вариантов поведения (strategy) задаются статически инстанцированием типа конкретными параметрами.

[Medium-rare]

Ну у меня в State Machine что-то подобное используется. Не буду же создавать множестов объектов StateMachine параметризованных для каждого возможного State. Каждый State имеет свой virtual State* Handle(). Похэндлил, и отдал новый State.

[Мальчик-Одуванчик]

. Не буду же создавать множестов объектов StateMachine параметризованных для каждого возможного State. .

Если не ошибаюсь, то в примере описанном в книге Абрахамсона и Гуртового именно так и делается при создании DSL описывающего данную предметную область.

[crypto5]

Так а несложно выложить простенький код с примером применения специализации по отношению к шаблону strategy? Этп ведь наверное не больше 10 строк кода?

typedef char (&MyStrategy)[1];
template <typename > class Strategy {};
template <> class Strategy <MyStrategy>{
public:
void use() { cout << "MyStrategy" << endl;}
};
template <typename T> class Context {
T strategy_;
public:
void usestrategy() {strategy_.use();}
};

Мне кажется что в вашем примере templates и специализация иррелевантны, всего этого можно достичь и без templates, например код на джаве:

Code: Select all

class StrategyImpl1 {
  public static void m() {System.out.println("Impl1");};
}
class StrategyImpl2 {
  public static void m() {System.out.println("Impl2");};
}
class Strategy extends StrategyImpl1 {};

class Context {
  Strategy strategy;
  void run() {strategy.m();};
}

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

[Интеррапт]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

[Medium-rare]

. Не буду же создавать множестов объектов StateMachine параметризованных для каждого возможного State. .

Если не ошибаюсь, то в примере описанном в книге Абрахамсона и Гуртового именно так и делается при создании DSL описывающего данную предметную область.

StateMachine для чего-то, какой-то системы или подсистемы, по определению должна быть одна. У неё один текущий State.

[crypto5]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

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

[Мальчик-Одуванчик]

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

В примере я много чего опустил, но даже из него видно что функции-члены специализации параметризованного типа не статические. Собственно можно задать различные специализации
template<> class Strategy <Strategy_1> {
int i;
public:
void use() { ++i; ....}
}
понятно что функция в этом случае статической быть уже не может.

[crypto5]

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

В примере я много чего опустил, но даже из него видно что функции-члены специализации параметризованного типа не статические. Собственно можно задать различные специализации
template<> class Strategy <Strategy_1> {
int i;
public:
void use() { ++i; ....}
}
понятно что функция в этом случае статической быть уже не может.

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

[Мальчик-Одуванчик]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

Думаю сакральный смысл как раз в том что статический полиморфизм в Java определен только для статических методов. Во всех остальных случаях имеет место динамический полиморфизм.
Но собственно речь не сколько об этом а об убирании лишней косвенности в виде наследования

[Мальчик-Одуванчик]

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

В примере я много чего опустил, но даже из него видно что функции-члены специализации параметризованного типа не статические. Собственно можно задать различные специализации
template<> class Strategy <Strategy_1> {
int i;
public:
void use() { ++i; ....}
}
понятно что функция в этом случае статической быть уже не может.

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

Конечно можно но речь изначально шла не об этом.
А что касается "нестатических невиртуальных функций" -а разве любой метод обычного класса не является таковым в отсутствии наследования от него?
А вот чего определенно нет в Java так это статического полиморфизма который позволяет плюсам написания кода в парадигме функционального программирования.

[crypto5]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

Думаю сакральный смысл как раз в том что статический полиморфизм в Java определен только для статических методов. Во всех остальных случаях имеет место динамический полиморфизм.
Но собственно речь не сколько об этом а об убирании лишней косвенности в виде наследования

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

[crypto5]

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

В примере я много чего опустил, но даже из него видно что функции-члены специализации параметризованного типа не статические. Собственно можно задать различные специализации
template<> class Strategy <Strategy_1> {
int i;
public:
void use() { ++i; ....}
}
понятно что функция в этом случае статической быть уже не может.

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

Конечно можно но речь изначально шла не об этом.

А о чем?

[Мальчик-Одуванчик]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

Думаю сакральный смысл как раз в том что статический полиморфизм в Java определен только для статических методов. Во всех остальных случаях имеет место динамический полиморфизм.
Но собственно речь не сколько об этом а об убирании лишней косвенности в виде наследования

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

Убирается наследование - исчезают виртуальные методы. Они же не сами по себе.
Собственно сам уровень косвенности - базовый класс с виртуальной функцией и наследники с ее имплементацией
Именно это и имел ввиду говоря "А как по мне шаблоны удобнее чтобы убрать лишний уровень косвенности, который раньше имплементировался через виртуальные методы"
А Вы что подумали?

[crypto5]

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

А в чем в данном случае сакральный смысл использовать static в сигнатуре метода? Думаю, что компилятор Джавы тоже удивится и сделает замечание, что доступ к статистическому методу должен идти не через референс, а через имя класса.

Думаю сакральный смысл как раз в том что статический полиморфизм в Java определен только для статических методов. Во всех остальных случаях имеет место динамический полиморфизм.
Но собственно речь не сколько об этом а об убирании лишней косвенности в виде наследования

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

Убирается наследование - исчезают виртуальные методы. Они же не сами по себе.
Собственно сам уровень косвенности - базовый класс с виртуальной функцией и наследники с ее имплементацией
Именно это и имел ввиду говоря "А как по мне шаблоны удобнее чтобы убрать лишний уровень косвенности, который раньше имплементировался через виртуальные методы"
А Вы что подумали?

Я вот прочитал статью про специализацию шаблонов и у меня в голове очевидности не осталось по этому вопросу, поэтому я ее точно не выбираю ))
А подумал я в точности то что вы написали - что нужно избавится от виртуальных методов.

[Мальчик-Одуванчик]

Я вот прочитал статью про специализацию шаблонов и у меня в голове очевидности не осталось по этому вопросу, поэтому я ее точно не выбираю ))
А подумал я в точности то что вы написали - что нужно избавится от виртуальных методов.

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