Ok many thx all:

1) For the people responding 'why do you do this', answer: it was an
academic question. Of course you can work with overloads etc.
2) I posted earlier also a c++ problem which was correctly rejected by
the compiler. At least some people and the Comeau compiler think so.
Next time I let Comeau take a look at it. If it compiles we have a
problem
3) And some day maybe I will spend time trying to understand the whole
unreadable c++ standard.

Only strange thing is that the inline variant does compile

template <typename T>
class KAEx_T
{
public:
template <typename U>
void Foo(const U& rU)
{}

template <>
void Foo(const std::string& rstr)
{}
};

which is either incorrectly accepted by VC++, or c++ is strange by
allowing more or less the same concept depending on how its
implemented.

Me

Re: Explicit Specialization of Member Templates 2 by comeau

comeau
Tue Aug 19 08:43:29 CDT 2003

In article <e3e73a80.0308182342.3414ed8@posting.google.com>,
Programmer_blabla <programmer_blabla@hotmail.com> wrote:
>Ok many thx all:
>
>1) For the people responding 'why do you do this', answer: it was an
>academic question. Of course you can work with overloads etc.
>2) I posted earlier also a c++ problem which was correctly rejected by
>the compiler. At least some people and the Comeau compiler think so.
>Next time I let Comeau take a look at it. If it compiles we have a
>problem
>3) And some day maybe I will spend time trying to understand the whole
>unreadable c++ standard.
>
>Only strange thing is that the inline variant does compile
>
>template <typename T>
>class KAEx_T
>{
>public:
> template <typename U>
> void Foo(const U& rU)
> {}
>
> template <>
> void Foo(const std::string& rstr)
> {}
>};
>
>which is either incorrectly accepted by VC++, or c++ is strange by
>allowing more or less the same concept depending on how its
>implemented.

The above code is not valid accto Standard C++.
As you note VC++ accepts it (as does Comeau in MS mode,
but not in strict mode).
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: Explicit Specialization of Member Templates 2 by Doug

Doug
Tue Aug 19 12:20:33 CDT 2003

Greg Comeau wrote:

>In article <e3e73a80.0308182342.3414ed8@posting.google.com>,
>Programmer_blabla <programmer_blabla@hotmail.com> wrote:
>>Ok many thx all:
>>
>>1) For the people responding 'why do you do this', answer: it was an
>>academic question. Of course you can work with overloads etc.
>>2) I posted earlier also a c++ problem which was correctly rejected by
>>the compiler. At least some people and the Comeau compiler think so.
>>Next time I let Comeau take a look at it. If it compiles we have a
>>problem
>>3) And some day maybe I will spend time trying to understand the whole
>>unreadable c++ standard.
>>
>>Only strange thing is that the inline variant does compile
>>
>>template <typename T>
>>class KAEx_T
>>{
>>public:
>> template <typename U>
>> void Foo(const U& rU)
>> {}
>>
>> template <>
>> void Foo(const std::string& rstr)
>> {}
>>};
>>
>>which is either incorrectly accepted by VC++, or c++ is strange by
>>allowing more or less the same concept depending on how its
>>implemented.
>
>The above code is not valid accto Standard C++.
>As you note VC++ accepts it (as does Comeau in MS mode,
>but not in strict mode).

Do you happen to know why it's forbidden?

--
Doug Harrison
Microsoft MVP - Visual C++

Re: Explicit Specialization of Member Templates 2 by comeau

comeau
Tue Aug 19 14:32:03 CDT 2003

In article <01n4kv8setfucphsdva98dgcjev79dr7er@4ax.com>,
Doug Harrison [MVP] <dsh@mvps.org> wrote:
>Greg Comeau wrote:
>>In article <e3e73a80.0308182342.3414ed8@posting.google.com>,
>>Programmer_blabla <programmer_blabla@hotmail.com> wrote:
>>>Ok many thx all:
>>>
>>>1) For the people responding 'why do you do this', answer: it was an
>>>academic question. Of course you can work with overloads etc.
>>>2) I posted earlier also a c++ problem which was correctly rejected by
>>>the compiler. At least some people and the Comeau compiler think so.
>>>Next time I let Comeau take a look at it. If it compiles we have a
>>>problem
>>>3) And some day maybe I will spend time trying to understand the whole
>>>unreadable c++ standard.
>>>
>>>Only strange thing is that the inline variant does compile
>>>
>>>template <typename T>
>>>class KAEx_T
>>>{
>>>public:
>>> template <typename U>
>>> void Foo(const U& rU)
>>> {}
>>>
>>> template <>
>>> void Foo(const std::string& rstr)
>>> {}
>>>};
>>>
>>>which is either incorrectly accepted by VC++, or c++ is strange by
>>>allowing more or less the same concept depending on how its
>>>implemented.
>>
>>The above code is not valid accto Standard C++.
>>As you note VC++ accepts it (as does Comeau in MS mode,
>>but not in strict mode).
>
>Do you happen to know why it's forbidden?

The general rule is that (all) specializations be
in namespace scope. As I recall it, allowing it in
class scope was consider too messy, it would need lots
of special rules, involving ordering, accessibility, etc.
Consider for instance:

template <typename T>
class KAEx_T
{
public:
template <typename U>
void Foo(const U& rU)
{}

private:
template <>
void Foo(const std::string& rstr)
{}
};

It also seems to hijack specializations, in that you then can't
always specialize the class itself. IOWs, it was thought that
people may not want to be using this capability (many things
were possible, and the committee did have to control themselves
to allow the kitchen sink).

There was probably some corner cases too presented
at the time which either broke things or became
confusing even if the behavior could be defined.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: Explicit Specialization of Member Templates 2 by Igor

Igor
Tue Aug 19 15:35:44 CDT 2003

"Greg Comeau" <comeau@panix.com> wrote in message
news:bhttvj$5ma$1@panix2.panix.com...
> In article <01n4kv8setfucphsdva98dgcjev79dr7er@4ax.com>,
> Doug Harrison [MVP] <dsh@mvps.org> wrote:
> >Do you happen to know why it's forbidden?
>
> The general rule is that (all) specializations be
> in namespace scope. As I recall it, allowing it in
> class scope was consider too messy, it would need lots
> of special rules, involving ordering, accessibility, etc.
> Consider for instance:
>
> template <typename T>
> class KAEx_T
> {
> public:
> template <typename U>
> void Foo(const U& rU)
> {}
>
> private:
> template <>
> void Foo(const std::string& rstr)
> {}
> };

OK, I understand that, there's even a core language issue closed as NAD
that discusses that. The interesting question is, why isn't out-of-class
specialization allowed:

template <typename T>
template<>
void KAEx_T<T>::Foo(const std::string& rstr)
{ /*...*/ }

I first thought 14.7.3/18 covers it, but Doug points out (correctly as
far as I can see) that it does not really apply. Moreover, 14.7.3/1
explicitly states that member function template of a class template can
be explicitly specialized. What would be the syntax for doing this?
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Re: Explicit Specialization of Member Templates 2 by comeau

comeau
Wed Aug 20 00:06:34 CDT 2003

In article <u8HuQGpZDHA.1744@TK2MSFTNGP12.phx.gbl>,
Igor Tandetnik <itandetnik@mvps.org> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:bhttvj$5ma$1@panix2.panix.com...
>> In article <01n4kv8setfucphsdva98dgcjev79dr7er@4ax.com>,
>> Doug Harrison [MVP] <dsh@mvps.org> wrote:
>> >Do you happen to know why it's forbidden?
>>
>> The general rule is that (all) specializations be
>> in namespace scope. As I recall it, allowing it in
>> class scope was consider too messy, it would need lots
>> of special rules, involving ordering, accessibility, etc.
>> Consider for instance:
>>
>> template <typename T>
>> class KAEx_T
>> {
>> public:
>> template <typename U>
>> void Foo(const U& rU)
>> {}
>>
>> private:
>> template <>
>> void Foo(const std::string& rstr)
>> {}
>> };
>
>OK, I understand that, there's even a core language issue closed as NAD
>that discusses that.

If it's the one I'm thinking of (core issue 44) it is closed but
taken as a defect.

>The interesting question is, why isn't out-of-class
>specialization allowed:
>
>template <typename T>
>template<>
>void KAEx_T<T>::Foo(const std::string& rstr)
>{ /*...*/ }
>
>I first thought 14.7.3/18 covers it, but Doug points out (correctly as
>far as I can see) that it does not really apply.

If it's what I'm thinking of, /18 says the above form is not allowed.

>Moreover, 14.7.3/1
>explicitly states that member function template of a class template can
>be explicitly specialized. What would be the syntax for doing this?

They can. However, above you're trying to specialize the member
whereas the class does not exist yet.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: Explicit Specialization of Member Templates 2 by comeau

comeau
Wed Aug 20 00:31:31 CDT 2003

In article <t745kvgcpg8fquc6iqtetesrocoi2rdfa0@4ax.com>,
Doug Harrison [MVP] <dsh@mvps.org> wrote:
>Greg Comeau wrote:
>>The general rule is that (all) specializations be
>>in namespace scope. As I recall it, allowing it in
>>class scope was consider too messy, it would need lots
>>of special rules, involving ordering, accessibility, etc.
>>Consider for instance:
>>
>>template <typename T>
>>class KAEx_T
>>{
>>public:
>> template <typename U>
>> void Foo(const U& rU)
>> {}
>>
>>private:
>> template <>
>> void Foo(const std::string& rstr)
>> {}
>>};
>>
>>It also seems to hijack specializations, in that you then can't
>>always specialize the class itself.
>
>If I was to explicitly specialize KAEx_T above, then IIRC, nothing in the
>primary template is carried over into the specialization, so I don't see the
>hijacking problem.

I probably worded that too briefly. I guess I had two points.
The first being that the operative word is "seems".
The second is that, yes, you can specialize the "secondary"
template, however, using just the above, if you were to do
something like this, you couldn't, because it would be
a duplicate definition:

template<>
template<> void KAEx_t<long>::Foo(const std::string& rstr)
{
// I dunno, a debug version
}

>>IOWs, it was thought that
>>people may not want to be using this capability (many things
>>were possible, and the committee did have to control themselves
>>to allow the kitchen sink).
>
>I shudder to think at what's more than the kitchen sink. :)

Warts aside, probably the above will be allowed in C++0x

>>There was probably some corner cases too presented
>>at the time which either broke things or became
>>confusing even if the behavior could be defined.
>
>No doubt. I so wish a rationale had been published along with the standard,
>as many things it says are enigmatic.

Yes, that would be nice. The job would be daunting though.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: Explicit Specialization of Member Templates 2 by Igor

Igor
Wed Aug 20 09:10:19 CDT 2003

"Greg Comeau" <comeau@panix.com> wrote in message
news:bhuvkq$nse$1@panix1.panix.com...
> In article <u8HuQGpZDHA.1744@TK2MSFTNGP12.phx.gbl>,
> Igor Tandetnik <itandetnik@mvps.org> wrote:
> >The interesting question is, why isn't out-of-class
> >specialization allowed:
> >
> >template <typename T>
> >template<>
> >void KAEx_T<T>::Foo(const std::string& rstr)
> >{ /*...*/ }
> >
> >I first thought 14.7.3/18 covers it, but Doug points out (correctly
as
> >far as I can see) that it does not really apply.
>
> If it's what I'm thinking of, /18 says the above form is not allowed.

Which part of it? The only sentence in this clause that prohibits
something is

...the declaration shall not explicitly specialize a class member
template if its enclosing class templates are not explicitly specialized
as well.

but it talks about class member template, not member function template.

> >Moreover, 14.7.3/1
> >explicitly states that member function template of a class template
can
> >be explicitly specialized. What would be the syntax for doing this?
>
> They can. However, above you're trying to specialize the member
> whereas the class does not exist yet.

I don't follow. Let's consider a complete example:

template <typename T>
struct S
{
template <typename U>
void f(U);
};

// member function template definition
template <typename T>
template <typename U>
void S<T>::f(U) {}

// Now I want to specialize f<int>. What's the syntax for this?
// This syntax does not work - why?
template <typename T>
template<>
void S<T>::f<int>(int) {}

S<char> s;
s.f(1.0); // should call general implementation
s.f(1); // should call f<int> specialization


How should I go about specializing f<int> for all instantiations of
S<T>? If I can't, where does the standard say so, and what does the
statement in 14.7.3./1 mean - the one that says it is possible to
explicitly specialize a member function template of a class template?
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken