views:

301

answers:

2

Is it possible to specialize particular members of a template class? Something like:

template <typename T,bool B>
struct X
{
    void Specialized();
};

template <typename T>
void X<T,true>::Specialized()
{
    ...
}

template <typename T>
void X<T,false>::Specialized()
{
    ...
}

Ofcourse, this code isn't valid.

+1  A: 

This is what I came up with, not so bad :)

//The generic template is by default 'flag == false'
template <class Type, bool flag>
struct something
{
    void doSomething()
    {
     std::cout << "something. flag == false";
    }
};

template <class Type>
struct something<Type, true> : public something<Type, false>
{
    void doSomething() // override original dosomething!
    {
     std::cout << "something. flag == true";
    }
};

int main()
{
    something<int, false> falseSomething;
    something<int, true> trueSomething;

    falseSomething.doSomething();
    trueSomething.doSomething();
}
AraK
+7  A: 

You can only specialize it explicitly by providing all template arguments. No partial specialization for member functions of class templates is allowed.

template <typename T,bool B>
struct X
{
    void Specialized();
};

// works
template <>
void X<int,true>::Specialized()
{
    ...
}

A work around is to introduce overloaded functions, which have the benefit of still being in the same class, and so they have the same access to member variables, functions and stuffs

// "maps" a bool value to a struct type
template<bool B> struct i2t { };

template <typename T,bool B>
struct X
{
    void Specialized() { SpecializedImpl(i2t<B>()); }

private:
    void SpecializedImpl(i2t<true>) { 
      // ...
    }

    void SpecializedImpl(i2t<false>) { 
      // ...
    }
};

Note that by passing along to the overloaded functions and pushing the template parameters into a function parameter, you may arbitrary "specialize" your functions, and may also templatize them as needed. Another common technique is to defer to a class template defined separately

template<typename T, bool B>
struct SpecializedImpl;

template<typename T>
struct SpecializedImpl<T, true> {
  static void call() { 
    // ...
  }
};

template<typename T>
struct SpecializedImpl<T, false> {
  static void call() { 
    // ...
  }
};

template <typename T,bool B>
struct X
{
    void Specialized() { SpecializedImpl<T, B>::call(); }
};

I find that usually requires more code and i find the function overload easier to handle, while others prefer the defer to class template way. In the end it's a matter of taste i think. In this case, you could have put that other template inside X too as a nested template - in other cases where you explicitly specialize instead of only partially, then you can't do that, because you can place explicit specializations only at namespace scope, not into class scope.

You could also create such a SpecializedImpl template just for purpose of function overloading (it then works similar to our i2t of before), as the following variant demonstrates which leaves the first parameter variable too (so you may call it with other types - not just with the current instantiation's template parameters)

// maps a type and non-type parameter to a struct type
template<typename T, bool B>
struct SpecializedImpl { };

template <typename T,bool B>
struct X
{
    void Specialized() { Specialized(SpecializedImpl<T, B>()); }

private:
    template<typename U>
    void Specialized(SpecializedImpl<U, true>) {
      // ...
    }

    template<typename U>
    void Specialized(SpecializedImpl<U, false>) {
      // ...
    }
};

I think sometimes, deferring to another template is better (when it comes to such cases as arrays and pointers, overloading can tricky and just forwarding to a class template has been easier for me then), and sometimes just overloading within the template is better - especially if you really forward function arguments and if you touch the classes' member variables a lot (in this case we didn't have function arguments, so we had to "synthesize" our own function argument so we could use overloading :)).

Johannes Schaub - litb
+1 Nice elegant solutions in front of my eyes.
AraK
thanks, appreciated :)
Johannes Schaub - litb