Abnormal programming
C++
Haskell
Comments 15
+2
Какое-то сумбурное изложение мыслей. Непонятно что и зачем. Я конечно хаскель не знаю, но почему-то есть чувство, что тащить функциональщину в таком виде в C++ просто не стоит. С++ является процедурным языком программирования. И не стоит тащить функциональщинку в процедурщину. Да, функциональный подход используется в компайл-тайм метапрограмминге, но в вашем случае на всю катушку используется рантайм.

Ну и в статье такие сумбурные вещи написаны, что я чуть со стула не упал.

>> Основная идея классов типов в отделении реализации интерфейса от структуры данных.
Основная идея интерфейсов в отделении реализации от объявления.

>> Код, использующий этот интерфейс, не обязан знать подробности его реализации.
Если код знает о особенностях реализации интерфейса, то уже потребно рубить руки программисту сделавшему так.

>> К сожалению, шаблон std::vector имеет два параметра (второй отвечает за политику аллокации и
>> может подставляться поумолчанию). Современный gcc не позволяет его передавать в шаблон,
>> который ждет шаблон с одним параметром (если мне память не изменяет, раньше
>> таких строгостей не было).
Таков стандарт и это правильное поведение, что дефолтные шаблонные параметры не разворачиваются, делается либо обертка, либо используется type alias (из C++11).

Больше не смотрел, сил не хватило.

Посмотрите на boost.mpl, посмотрите нормально на реализацию stl и не городите огороды, описанные вещи делаются элементарно, без какой-либо функциональщины.
+4
>> Основная идея классов типов в отделении реализации интерфейса от структуры данных.
Основная идея интерфейсов в отделении реализации от объявления.

Зря вы так.
Основная суть интерфейсов — подключать интерфейсы к классам объектов.
А основная суть классов типов — подключать интерфейсы отдельно от класса объекта.
+1
Классы типов не связаны с функциональным программированием.

В ООП реализация интерфейса зашита в типе. Если есть готовый тип данных (класс), то нельзя штатными способами заставить созданные объекты поддерживать некий интерфейс, кроме как подправив исходники (или прототип в некоторых языках, но это рискованная техника). Классы типов позволяют отвязать реализацию интерфейса от самого типа — можно реализовать нужный интерфейс для библиотечных объектов не изменяя исходников библиотеки. И писать код, работающий с любым типом, для которого данный интерфейс реализован.

«Функциональщины», кроме использования указателей на функции и примеры на Haskell, в этой статье нет. Все вполне императивно.
0
Может быть. На C# не смотрел, но слышал что там много интересного.
0
Extention method не сделает целевой класс реализующим нужный интерфейс. Классы типов позволяют делать тип Т реализующим интерфейс И, не изменяя ни Т, ни И.
Классы типов больше похожи на шаблон Адаптер, только неявный.
0
При чтении таких статьях мне всё время мерещится картинка с троллейбусом и буханкой…
0
Если интересно:
C++Concepts — отвергнутое предложение о введении концептов (аналог классов типов) в C++
0
Страуструпп не любит вводить новые конструкции, если их можно хоть как-то выразить через старые. Его сложность и многословность не пугают.
Only those users with full accounts are able to leave comments. , please.