Pull to refresh

Comments 6

Спасибо за статью.
Полезный подход, в том числе и для локальных оптимизаций.
Отмечу один небольшой недостаток CRTP: если в базовом классе не просто интерфейс, а содержит какие-нибудь методы, то для каждого класса-потомка код базовых методов будет дублироваться. Потому что для компилятора это совершенно разные классы.
Я когда-то давно в таком стиле написал библиотеку для работы с графами.
Не знал, что этот стиль программирования так называется.
Вы говорите, что:
Объекты таких [шаблонных] типов без дополнительных ухищрений (см. boost::variant, boost::tuple, boost::any, boost::fusion etc.) невозможно положить в один контейнер и следовательно пакетно обработать.

А при использовании CRTP такое возможно? Мне почему-то кажется, что тоже — нет.

И ещё момент. Раз мы в базовом классе (интерфейсе) имеем шаблонный параметр:

template<typename D>
struct base
{
    void foo() {static_cast<D*>(this)->bar();}
};


значит клиентскому коду, чтобы работать с экземпляром такого класса (интерфейса), необходимо видеть определение D, верно ведь? Тогда как одним из преимуществ интерфейсов является ограничение знаний клиента о конкретной реализации этого интерфейса.
А при использовании CRTP такое возможно? Мне почему-то кажется, что тоже — нет.

А я разве писал, что CRTP решает эту проблему? Это не универсальное средство на все случаи жизни. Под какие-то архитектурные решения оно подходит, под другие — нет. И к тому же пакетная обработка все-таки возможна и и не слишком сложна с использованием доп. средств типа variant или fusion.
Очень похоже на политики описываемые Александреску.
Sign up to leave a comment.

Articles

Change theme settings