Comments 15
Сложно, многословно, медленно, утекает память.
Какое-то сумбурное изложение мыслей. Непонятно что и зачем. Я конечно хаскель не знаю, но почему-то есть чувство, что тащить функциональщину в таком виде в C++ просто не стоит. С++ является процедурным языком программирования. И не стоит тащить функциональщинку в процедурщину. Да, функциональный подход используется в компайл-тайм метапрограмминге, но в вашем случае на всю катушку используется рантайм.
Ну и в статье такие сумбурные вещи написаны, что я чуть со стула не упал.
>> Основная идея классов типов в отделении реализации интерфейса от структуры данных.
Основная идея интерфейсов в отделении реализации от объявления.
>> Код, использующий этот интерфейс, не обязан знать подробности его реализации.
Если код знает о особенностях реализации интерфейса, то уже потребно рубить руки программисту сделавшему так.
>> К сожалению, шаблон std::vector имеет два параметра (второй отвечает за политику аллокации и
>> может подставляться поумолчанию). Современный gcc не позволяет его передавать в шаблон,
>> который ждет шаблон с одним параметром (если мне память не изменяет, раньше
>> таких строгостей не было).
Таков стандарт и это правильное поведение, что дефолтные шаблонные параметры не разворачиваются, делается либо обертка, либо используется type alias (из C++11).
Больше не смотрел, сил не хватило.
Посмотрите на boost.mpl, посмотрите нормально на реализацию stl и не городите огороды, описанные вещи делаются элементарно, без какой-либо функциональщины.
Ну и в статье такие сумбурные вещи написаны, что я чуть со стула не упал.
>> Основная идея классов типов в отделении реализации интерфейса от структуры данных.
Основная идея интерфейсов в отделении реализации от объявления.
>> Код, использующий этот интерфейс, не обязан знать подробности его реализации.
Если код знает о особенностях реализации интерфейса, то уже потребно рубить руки программисту сделавшему так.
>> К сожалению, шаблон std::vector имеет два параметра (второй отвечает за политику аллокации и
>> может подставляться поумолчанию). Современный gcc не позволяет его передавать в шаблон,
>> который ждет шаблон с одним параметром (если мне память не изменяет, раньше
>> таких строгостей не было).
Таков стандарт и это правильное поведение, что дефолтные шаблонные параметры не разворачиваются, делается либо обертка, либо используется type alias (из C++11).
Больше не смотрел, сил не хватило.
Посмотрите на boost.mpl, посмотрите нормально на реализацию stl и не городите огороды, описанные вещи делаются элементарно, без какой-либо функциональщины.
>> Основная идея классов типов в отделении реализации интерфейса от структуры данных.
Основная идея интерфейсов в отделении реализации от объявления.
Зря вы так.
Основная суть интерфейсов — подключать интерфейсы к классам объектов.
А основная суть классов типов — подключать интерфейсы отдельно от класса объекта.
Основная идея интерфейсов в отделении реализации от объявления.
Зря вы так.
Основная суть интерфейсов — подключать интерфейсы к классам объектов.
А основная суть классов типов — подключать интерфейсы отдельно от класса объекта.
Классы типов не связаны с функциональным программированием.
В ООП реализация интерфейса зашита в типе. Если есть готовый тип данных (класс), то нельзя штатными способами заставить созданные объекты поддерживать некий интерфейс, кроме как подправив исходники (или прототип в некоторых языках, но это рискованная техника). Классы типов позволяют отвязать реализацию интерфейса от самого типа — можно реализовать нужный интерфейс для библиотечных объектов не изменяя исходников библиотеки. И писать код, работающий с любым типом, для которого данный интерфейс реализован.
«Функциональщины», кроме использования указателей на функции и примеры на Haskell, в этой статье нет. Все вполне императивно.
В ООП реализация интерфейса зашита в типе. Если есть готовый тип данных (класс), то нельзя штатными способами заставить созданные объекты поддерживать некий интерфейс, кроме как подправив исходники (или прототип в некоторых языках, но это рискованная техника). Классы типов позволяют отвязать реализацию интерфейса от самого типа — можно реализовать нужный интерфейс для библиотечных объектов не изменяя исходников библиотеки. И писать код, работающий с любым типом, для которого данный интерфейс реализован.
«Функциональщины», кроме использования указателей на функции и примеры на Haskell, в этой статье нет. Все вполне императивно.
Это как Extention methods из C# что ли?
При чтении таких статьях мне всё время мерещится картинка с троллейбусом и буханкой…
Если интересно:
C++Concepts — отвергнутое предложение о введении концептов (аналог классов типов) в C++
C++Concepts — отвергнутое предложение о введении концептов (аналог классов типов) в C++
Страуструпп не любит вводить новые конструкции, если их можно хоть как-то выразить через старые. Его сложность и многословность не пугают.
я так понимаю, это устаревшая тяжеловесная реализация.
Есть гораздо более легковесное предложение, у которогое возможно будущее: Concepts Lite: Constraining Templates with Predicates.
Бьёрн рассказывал о нём на GoingNative 2013 (о концептах примерно с 1:00:00).
Есть гораздо более легковесное предложение, у которогое возможно будущее: Concepts Lite: Constraining Templates with Predicates.
Бьёрн рассказывал о нём на GoingNative 2013 (о концептах примерно с 1:00:00).
del
Sign up to leave a comment.
Классы типов на C++