Avoid typename repetition in template specialization

Avoid typename repetition in template specialization

[Frank Winter]

Dear all,

suppose a templated class:

template< typename T >
struct A {
 	const T& some_function( const T& )
 	T i[10];
};

and a specialization for some type, say
PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns >:

template<>
struct A<PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > > {
 	const PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns >& 
some_function( const PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns 
>& )
 	PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > i[10];
};

Is there a way to avoid the redundant typing of the specialized typename 
in the template specialization?

I know, using templates would exactly avoid this. But I really need 
this kind of specialization to specialize the some_function

I would not like to use the preprocessor. Like:

#define PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T
template<>
struct A<T> {
 	public:
 	const T& some_function( const T& )
 	T i[10];
}
#undef T


Isn't there a template-way of doing this?


Best regards,
Frank Winter


--

Institut fuer theoretische Physik
Universitaet Regensburg
Universitaetsstr. 31
93053 Regensburg
Germany

office +49 (0)941 943 2085

Re: Avoid typename repetition in template specialization

[Axel Freyn]

Hi Frank,


On Fri, Apr 09, 2010 at 03:16:27PM +0200, Frank Winter wrote:
> suppose a templated class:
>
> template< typename T >
> struct A {
> 	const T& some_function( const T& )
> 	T i[10];
> };
>
> and a specialization for some type, say
> PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns >:
>
> template<>
> struct A<PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > > {
> 	const PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns >&  
> some_function( const PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns 
> 
>> & )
> 	PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > i[10];
> };
>
> Is there a way to avoid the redundant typing of the specialized typename  
> in the template specialization?
>
> I know, using templates would exactly avoid this. But I really need this 
> kind of specialization to specialize the some_function
>
> I would not like to use the preprocessor. Like:
>
> #define PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T
> template<>
> struct A<T> {
> 	public:
> 	const T& some_function( const T& )
> 	T i[10];
> }
> #undef T
>
>
> Isn't there a template-way of doing this?

I'm not sure that I understood your question correctly, but the easiest
way I see would be to use a typedef in the specialization -- then it's
sufficient to type the long typename only twice ;-)):

template<>
struct A<PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > > {
  typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T;
  const T& some_function( const T & );
  T i[10];
};

Or of course you could do the typedef "outside" of the template (this
would however introduce the new name "specialized_type" into your
namespace - which might be problematic if you have many constructs like
that...) :

typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > specialized_type;
template<>
struct A<specialized_type > {
  const specialized_type& some_function( const specialized_type & );
  specialized_type i[10];
};


HTH,

Axel

Re: Avoid typename repetition in template specialization

[Frank Winter]

Dear all,

Thanks John and Axel!

But, as I have a lot of these constructs typedef is exactly the problem:

   typedef PScalar< PColorMatrix< RComplex<REAL64>, Nc> > T1;
   typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T2;
   typedef OpMultiply Op;
   template<>
   inline BinaryReturn< T1 , T2 , Op >::Type_t
   operator*(const T1& l, const T2& r )
   {
     BinaryReturn< T1 , T2 , Op >::Type_t d;
     // code
     return d;
   }

now, this conflicts:

   typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T1;
   typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T2;
   typedef OpMultiply Op;
   template<>
   inline BinaryReturn< T1 , T2 , Op >::Type_t
   operator+(const T1& l, const T2& r )
   {
     BinaryReturn< T1 , T2 , Op >::Type_t d;
 	// code
     return d;
   }

If there would be a way to undefine a typename in the actual namespace 
this would help a lot in this case. Is there functionality for this or is 
there a workaround for my case that occurs to you?

Best regards,
Frank Winter

RE: Avoid typename repetition in template specialization

[John (Eljay) Love-Jensen]

Hi Frank,

> If there would be a way to undefine a typename in the actual namespace this would help a lot in this case.

It would help if there was an "undefine", or at least a way to scope them that would work in this situation.  But there is not, as far as I am aware.

> Is there functionality for this or is there a workaround for my case that occurs to you?

#define T1 PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns >
// use T1
#undef T1

But I strongly dislike the preprocessor, since I much prefer programming in C++ rather than "programming in preprocessor macro magic".

I would use this approach:
typedef PScalar< PColorMatrix< RComplex<REAL64>, Nc> > TScalarMatrix;
typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > TSpinVector;
template<>
inline BinaryReturn< TScalarMatrix , TSpinVector , OpMultiply >::Type_t
operator+(const T1& l, const T2& r )
{
   BinaryReturn< TScalarMatrix , TSpinVector , OpMultiply >::Type_t d;
    // code
   return d;
}

Although TScalarMatrix is probably more semantic detail (and longer to type) than you'd prefer over T1, it avoids the naming collision.

Sincerely,
--Eljay

Re: Avoid typename repetition in template specialization

[Axel Freyn]

Hi Frank,
On Fri, Apr 09, 2010 at 07:11:04AM -0700, John (Eljay) Love-Jensen wrote:
> 
> I would use this approach:
> typedef PScalar< PColorMatrix< RComplex<REAL64>, Nc> > TScalarMatrix;
> typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > TSpinVector;
> template<>
> inline BinaryReturn< TScalarMatrix , TSpinVector , OpMultiply >::Type_t
> operator+(const T1& l, const T2& r )
> {
>    BinaryReturn< TScalarMatrix , TSpinVector , OpMultiply >::Type_t d;
>     // code
>    return d;
> }
> 
> Although TScalarMatrix is probably more semantic detail (and longer to
> type) than you'd prefer over T1, it avoids the naming collision.

Maybe another solution (depending on your code - maybe the best is to
combine Eljay's suggestions of "understandable" typedefs with it) would
be to introduce additional, artifical namespaces - for each template
function one. This gives you a means to do "local typedefs":

namespace NS1{
  typedef PScalar< PColorMatrix< RComplex<REAL64>, Nc> > T1;
  typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T2;
  typedef OpMultiply Op;
  template<>
  inline BinaryReturn< T1 , T2 , Op >::Type_t
  operator*(const T1& l, const T2& r )
  {
    BinaryReturn< T1 , T2 , Op >::Type_t d;
    // code
    return d;
  }
}
using NS1::operator*;
namespace NS2{
  typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T1;
  typedef PSpinVector< PColorVector< RComplex<REAL64>, Nc>, Ns > T2;
  typedef OpMultiply Op;
  template<>
  inline BinaryReturn< T1 , T2 , Op >::Type_t
  operator+(const T1& l, const T2& r )
  {
    BinaryReturn< T1 , T2 , Op >::Type_t d;
        // code
    return d;
  }
}

using NS2::operator+;

Then you have no conflicts between the two T1's, as they are definied in
different namespaces - this code should compile fine, I believe.
However, this might render your code (and for sure: the error-messages
from the compiler;-)) more difficult to understand - and there are some
additional constraints, e.g. all template spezializations of a function
have to be in the same namespace:
namespace NS3{
  template <typename T> void Function(const T & x)
  {
     //code
  }
  typedef int T1;
  template <> void Function<T1>(const T1 & x)
  {
    //code
  }
}
using NS3::Function;

However, normal "overloading" can be done between two different
namespaces:
namespace NS4{
  void Function()
  {
    //code
  }
}
using NS4::Function;

should work.

HTH,

Axel