Comments 6
Спасибо за статью.
Полезный подход, в том числе и для локальных оптимизаций.
Полезный подход, в том числе и для локальных оптимизаций.
0
Отмечу один небольшой недостаток CRTP: если в базовом классе не просто интерфейс, а содержит какие-нибудь методы, то для каждого класса-потомка код базовых методов будет дублироваться. Потому что для компилятора это совершенно разные классы.
+1
Вы говорите, что:
А при использовании CRTP такое возможно? Мне почему-то кажется, что тоже — нет.
И ещё момент. Раз мы в базовом классе (интерфейсе) имеем шаблонный параметр:
значит клиентскому коду, чтобы работать с экземпляром такого класса (интерфейса), необходимо видеть определение D, верно ведь? Тогда как одним из преимуществ интерфейсов является ограничение знаний клиента о конкретной реализации этого интерфейса.
Объекты таких [шаблонных] типов без дополнительных ухищрений (см. boost::variant, boost::tuple, boost::any, boost::fusion etc.) невозможно положить в один контейнер и следовательно пакетно обработать.
А при использовании CRTP такое возможно? Мне почему-то кажется, что тоже — нет.
И ещё момент. Раз мы в базовом классе (интерфейсе) имеем шаблонный параметр:
template<typename D>
struct base
{
void foo() {static_cast<D*>(this)->bar();}
};
значит клиентскому коду, чтобы работать с экземпляром такого класса (интерфейса), необходимо видеть определение D, верно ведь? Тогда как одним из преимуществ интерфейсов является ограничение знаний клиента о конкретной реализации этого интерфейса.
+1
А при использовании CRTP такое возможно? Мне почему-то кажется, что тоже — нет.
А я разве писал, что CRTP решает эту проблему? Это не универсальное средство на все случаи жизни. Под какие-то архитектурные решения оно подходит, под другие — нет. И к тому же пакетная обработка все-таки возможна и и не слишком сложна с использованием доп. средств типа variant или fusion.
0
Очень похоже на политики описываемые Александреску.
0
Sign up to leave a comment.
Articles
Change theme settings
CRTP. Static polymorphism. MixIn. Размышления на тему