24

Template specialization does not take into account inheritance hierarchy. For example, if I specialize a template for Base and instantiate it with Derived, the specialization will not be chosen (see code (1) below).

This can be a major hindrance, because it sometimes lead to violation of the Liskov substitution principle. For instance, while working on this question, I noticed that I could not use Boost.Range algorithms with std::sub_match while I could with std::pair. Since sub_match inherits publicly from pair, common sense would dictate that I could substitute a sub_match everywhere a pair is used, but this fails due to trait classes using template specialization.

We can overcome this issue by using partial template specialization along with enable_if and is_base_of (see code (2)). Should I always favor this solution over full specialization, especially when writing library code? Are there any drawbacks to this approach that I have overseen? Is it a practice that you use or have seen used often?

Sample codes

(1)
#include <iostream>

struct Base {};
struct Derived : public Base {};

template < typename T >
struct Foo
{
    static void f() { std::cout << "Default" << std::endl; }
};

template <>
struct Foo< Base >
{
    static void f() { std::cout << "Base" << std::endl; }
};

int main()
{
    Foo<Derived>::f(); // prints "Default"
}

(2)
#include <type_traits>
#include <iostream>

struct Base {};
struct Derived : public Base {};

template <typename T, typename Enable = void>
struct Foo
{
    static void f() { std::cout << "Default" << std::endl; }
};

template <typename T>
struct Foo<
    T, typename 
    std::enable_if< std::is_base_of< Base, T >::value >::type
>
{
    static void f() { std::cout << "Base" << std::endl; }
};

int main()
{
    Foo<Derived>::f(); // prints "Base"
}
Community
  • 1
  • 1
Luc Touraille
  • 79,925
  • 15
  • 92
  • 137

1 Answers1

13

enable_if is more flexible

I think you should really prefer the enable_if approach: it enables everything that you could require and more.

E.g. there might be cases where a Derived class is Liskov-Subsitutable for a Base, but you [cannot assume/donot want to apply] the same traits/specializations to be valid (e.g. because the Base is POD class, whereas Derived ands non-POD behaviour or somehting like that that is completely orthogonal to class composition).

enable_if gives you the power to define exactly the conditions.

Hybrid approach

You could also achieve some middleground by implementing a traits class that derives some application-specific traits from general-purpose traits. The 'custom' traits could use the enable_if and meta-programming techniques to apply traits as polymorphically as you desire. That way, your actual implementations do not have to repeat some complicated enable_if/dispatch dance but instead can simply consume the custom-traits class (that hides the complexity).

I think some (many?) Boost libraries use the hybrid approach (I've seen it in some capacity where it bridges e.g. fusion/mpl, I think also various iterator traits in Spirit).

I personally like this approach because it can effectively isolate the 'plumbing' from the core-business of a library, making maintenance and documentation (!) a lot easier.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Very good answer, thank you. I think the hybrid approach you evoke can be related to [tag dispatching](http://www.boost.org/community/generic_programming.html#tag_dispatching): use a polymorphic trait class to obtain a tag, then use specialization or overloading based on tags (even though tags can sometimes be polymorphic, so they should perhaps be reserved for overloading...). – Luc Touraille Oct 28 '11 at 12:29
  • @sehe: e.g. you prefer something like mytraits::eligible_for_this_specialization::type instead of std::enable_if< std::is_base_of< Base, T >::value >::type ? – user396672 Oct 28 '11 at 13:19
  • @user396672: no, I'd rather avoid enable_if at all and use a `mytraits` directly. You can 'hide' the conditionals (possibly based on `enable_if`) inside you custom traits classes. – sehe Oct 28 '11 at 13:21
  • @user396672: One way to think about all this is to view the base template as a "Template Method" (the design pattern) that uses trait classes to provide customizable hooks. If one needs to customize some parts of the base template, she just needs to specialize ("override") the corresponding traits. If the entire structure/behavior must be changed, then one can still specialize ("override") the base template. – Luc Touraille Oct 28 '11 at 13:39
  • I think a good practice would be to encapsulate everything that could be subject to specialization into traits (which will possibly be specialized polymorphically), and encourage users to specialize the traits rather than the base template (pretty much like a Template Method is usually not virtual). – Luc Touraille Oct 28 '11 at 13:41
  • For the user convenience, traits specializations already provided by a library should probably be polymorphic, though. – Luc Touraille Oct 28 '11 at 13:47
  • I think that the library designers cannot decide that up front for all possible users of the library. (There may be border cases, like the range-traits example with `std::pair`; But in general I think that library designers should be very conservative when assuming e.g. that any class that __is-a__ `std::pair<...>` **must** also model a Range) – sehe Oct 28 '11 at 13:52
  • I do not blame Boost.Range developers, `std::pair` is not meant to be derived from anyway :). – Luc Touraille Oct 28 '11 at 13:57