According to my understanding of the standard, the following form of =
member=20
function specialization should be legal and possible:

//------ File specialClass.h --------------------------------------

template <class T>
class specialClass=20
{
public:
 specialClass();
 ~specialClass();
=09
 void OrdinaryMember(void);
 void SpecializedMember(void);
};

template <> void specialClass<int>::SpecializedMember(void);

//------ File specialClass.cpp --------------------------------------

/////////////////////////////////////////////////////////////////////////=

template <class T>
specialClass<T>::specialClass()
{
}
/////////////////////////////////////////////////////////////////////////=

template <class T>
specialClass<T>::~specialClass()
{
}
/////////////////////////////////////////////////////////////////////////=

template <class T>
void specialClass<T>::OrdinaryMember()
{
}
/////////////////////////////////////////////////////////////////////////=

template <class T>
void specialClass<T>::SpecializedMember()
{
 cerr << "specialClass<T>::SpecializedMember" << endl;
}
/////////////////////////////////////////////////////////////////////////=

template <>
void specialClass<int>::SpecializedMember()
{
 cerr << "specialClass<int>::SpecializedMember" << endl;
}

//------ File main.cpp --------------------------------------

#include "specialClass.h"

int main(void)
{
 specialClass<double> a;
 a.SpecializedMember();

 specialClass<int> b;
 b.SpecializedMember();

 return 0;
}

Sun's latest compiler version 4.2, claiming to be able to handle =
specialization=20
that way, however, gives the following error at link time:

Undefined   first referenced
 symbol         in file
specialClass<int>::specialClass<int>(void)             main.o
specialClass<int>::~specialClass<int>(void)             main.o

Sun's support (in Germany) claims that this is correct behavior: =
constructors,=20
destructors, and static members also needed specialization. Is this =
correct? I=20
cannot find anything in the draft standard that would prove this =
statement.

BTW: With the now deprecated old specialization method (using a =
Templates.opt=20
file) specialization still works.

Martin Fritz
____________________________________________________________________
 ___
|   anlagen-                  Universitaet Dortmund
|   |    ___                  Fachbereich Chemietechnik
|___|=3D=3D>|   steuerungs-       Lehrstuhl fuer =
Anlagensteuerungstechnik
  ^=3D=3D=3D=3D=3D|   |    ___          (Process Control Group)
        |___|=3D=3D>|   technik   Dipl.-Inform. Martin Fritz
          ^=3D=3D=3D=3D=3D|   |         D-44221 Dortmund (Germany)
                |___|         Tel. +49-231-9700-349 , Fax =
+49-231-755-5129
  =20
         email: Martin.Fritz@ast.chemietechnik.uni-dortmund.de
_____________________________________________________________________
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

According to my understanding of the standard, the following form of member function
specialization should be legal and possible:

//------ File specialClass.h --------------------------------------

template <class T>
class specialClass
{
public:
 specialClass();
 ~specialClass();

 void OrdinaryMember(void);
 void SpecializedMember(void);
};

template <> void specialClass<int>::SpecializedMember(void);

//------ File specialClass.cpp --------------------------------------

/////////////////////////////////////////////////////////////////////////
template <class T>
specialClass<T>::specialClass()
{
}
/////////////////////////////////////////////////////////////////////////
template <class T>
specialClass<T>::~specialClass()
{
}
/////////////////////////////////////////////////////////////////////////
template <class T>
void specialClass<T>::OrdinaryMember()
{
}
/////////////////////////////////////////////////////////////////////////
template <class T>
void specialClass<T>::SpecializedMember()
{
 cerr << "specialClass<T>::SpecializedMember" << endl;
}
/////////////////////////////////////////////////////////////////////////
template <>
void specialClass<int>::SpecializedMember()
{
 cerr << "specialClass<int>::SpecializedMember" << endl;
}

//------ File main.cpp --------------------------------------

#include "specialClass.h"

int main(void)
{
 specialClass<double> a;
 a.SpecializedMember();

 specialClass<int> b;
 b.SpecializedMember();

 return 0;
}

Sun's latest compiler version 4.2, claiming to be able to handle specialization that way, however, gives the following error at link time:

Undefined   first referenced
 symbol         in file
specialClass<int>::specialClass<int>(void)             main.o
specialClass<int>::~specialClass<int>(void)             main.o

Sun's support (in Germany) claims that this is correct behavior: constructors, destructors, and static members also needed specialization. Is this correct? I cannot find anything in the draft standard that would prove this statement.

BTW: With the now deprecated old specialization method (using a Templates.opt file) specialization still works.

Martin Fritz
____________________________________________________________________
 ___
|   anlagen-                  Universitaet Dortmund
|   |    ___                  Fachbereich Chemietechnik
|___|==>|   steuerungs-       Lehrstuhl fuer Anlagensteuerungstechnik
  ^=====|   |    ___          (Process Control Group)
        |___|==>|   technik   Dipl.-Inform. Martin Fritz
          ^=====|   |         D-44221 Dortmund (Germany)
                |___|         Tel. +49-231-9700-349 , Fax +49-231-755-5129

         email: Martin.Fritz@ast.chemietechnik.uni-dortmund.de
_____________________________________________________________________
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]