Ограничения параметров шаблона

Question

Я прочитал этот совет об ограничениях параметров шаблона и был смущен этой строкой:

template<class T> class Container : Derived_from<T,Mybase> {
    // ...
};

Что здесь происходит?Используется ли это просто старое наследство, чтобы компилятор проверял Derived_from для выполнения желаемой проверки?Почему это не приводит к генерации кода для Derived_from?

Спасибо.

Answer 1

Просто посмотрите на источник для Derived_from, который указан точно в том же URL-адресе, на который вы указали!

template<class T, class B> struct Derived_from {
    static void constraints(T* p) { B* pb = p; }
    Derived_from() { void(*p)(T*) = constraints; }
};

Какой код вы ожидаете создать, кроме этого единственного инициализатора в Derived_from конструктор, который должен (можно надеяться), будет легко компилятором оптимизировать?И статический метод constraints просто проверяет, что указатель на T может быть правильно назначен указателю на B - что, конечно, должно превратиться в чистую проверку во время компиляции, что T действительно получен из B, что является желаемым ограничением.

Answer 2

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

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

Обратите внимание, что при использовании этого метода проверки активируются только после создания объекта Container<T>.В противном случае конструктор Derived_from никогда не будет создан неявно, а проверки никогда не будут выполнены.

Есть способы, которые полностью это делают без какого-либо такого фиктивного кода, как boost::is_base_of.