Avoiding duplication of function definitions in partial template specializations when using traits

Question

How does one share common_fn() among all specializations (for Widget<A<T> > and Widget<B<T> >, no matter what T is) in the code below?

#include <cassert>

struct Afoo {};
struct Bfoo {};

template<typename T> struct A { typedef Afoo Foo; };
template<typename T> struct B { typedef Bfoo Foo; };

template<typename Type> struct Widget
{
    Widget() {}
    typename Type::Foo common_fn() { return Type::Foo(); }
    int uncommon_fn() { return 1; }
};

template<typename T> struct Widget<A<T> >
{
    Widget() {}
    int uncommon_fn() { return 2; }
};

int main()
{
    Widget<A<char> > WidgetAChar;
    assert( WidgetAChar.common_fn() == Afoo() ); // Error
    assert( WidgetAChar.uncommon_fn() == 2 );
}

I had tried earlier to simplify the question to what I thought was its essence, but it turns out that it is necessary to ask it in the context of partial specialization and traits.

Answer 1

It's a little unclear what you're aiming for, in particular whether uncommon_fn is really as simple as illustrated, or might be more.

But anyway, for the example code given, consider …

#include <cassert>
#include <typeinfo>

struct Afoo {};
struct Bfoo {};

template< class T > struct A { typedef Afoo Foo; };
template< class T > struct B { typedef Bfoo Foo; };

template< class Type >
struct UncommonResult { enum { value = 1 }; };

template< class Type >
struct UncommonResult< A< Type > > { enum { value = 2 }; };

template< class Type >
struct Widget
{
    Widget() {}
    typename Type::Foo common_fn() { return Type::Foo(); }
    int uncommon_fn() { return UncommonResult< Type >::value; }
};

int main()
{
    Widget<A<char> > WidgetAChar;
    assert( typeid( WidgetAChar.common_fn() ) == typeid( Afoo ) ); // OK
    assert( WidgetAChar.uncommon_fn() == 2 );
}

Generalizing this to handle a more general uncommon_fn shouldn't be hard.

You might also consider the inheritance trick that @iammilind showed for your previous question. It might be practically simpler. However, it adds the possibility of accessing a possibly "wrong" function implementation.

Cheers & hth.