Почему шаблоны mixins на С++ не более основаны?

Я использую шаблоны mixins на С++ много, но мне интересно, почему техника больше не используется. Похоже, что в конечном итоге в повторном использовании. Это сочетание мощности и эффективности является одной из причин, по которым я действительно люблю С++, и не вижу, как я перехожу на язык JIT.

Ответы

Ответ 1

Проблема с mixins - это... конструкция.

class Base1 { public: Base1(Dummy volatile&, int); };

class Base2 { public: Base2(Special const&, Special const&); };

И теперь мой супермикс:

template <typename T>
struct Mixin: T {};

Вы заметили проблему здесь? Как, черт возьми, я должен передать аргументы конструктору базового класса? Какой конструктор должен Mixin предложить?

Это сложная проблема, и она не была решена до тех пор, пока С++ 11 не улучшит язык для идеальной пересылки.

// std::foward is in <utility>

template <typename T>
struct Mixin: T {
  template <typename... Args>
  explicit Mixin(Args&&... args): T(std::forward<Args>(args...)) {}
};

Примечание: двойные проверки приветствуются

Итак, сейчас, мы действительно можем использовать mixins... и просто должны менять привычки людей:)

Конечно, действительно ли мы хотим, чтобы это был совершенно другой предмет.

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

Ответ 2

Шаблоны требуют, чтобы реализация была видимой в блоке перевода, а не только во время связи (адреса С++ 11, если вы будете использовать только указатель или ссылку на экземпляры). Это серьезная проблема для низкоуровневого кода в корпоративных средах: изменения в реализации будут инициироваться (может или не автоматически) массивные количества библиотек и клиентов для повторной компиляции, а не просто необходимость перезапуска.

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

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