explicit specialization in non-namespace scope

explicit specialization in non-namespace scope

[Oskar Enoksson]

The following code compiles with egcs 1.1 but not with egcs-19980914,
Which is wrong?

class X {
public:
  template<int M>
  int Factulty() { return M*Faculty<M-1>(); }
  template<>
  int Faculty<0>() { return 1; }
};

Thanks!

*/              Oskar Enoksson, Linkoping, Sweden                  /*

Re: explicit specialization in non-namespace scope

[Alexandre Oliva]

Oskar Enoksson <osken393@student.liu.se> writes:

> The following code compiles with egcs 1.1 but not with egcs-19980914,
> Which is wrong?

egcs 1.1.  According to the Standard, template specializations can
only be declared in namespace scope.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: explicit specialization in non-namespace scope

[Nathan Myers]

Alexandre Oliva wrote:
> 
> Oskar Enoksson <osken393@student.liu.se> writes:
> 
> > The following code compiles with egcs 1.1 but not with egcs-19980914,
> > Which is wrong?
> > struct X { 
> >   template<int M> int Faculty()    { return M*Faculty<M-1>(); }
> >   template<>      int Faculty<0>() { return 1; }
> > };
> 
> egcs 1.1.  According to the Standard, template specializations can
> only be declared in namespace scope.

I believe this is incorrect.  I find no such restriction.  In addition,
in 14.7.3 - Explicit specialization [temp.expl.spec] we have:

   -17- A member or a member template may be nested within many enclosing
   class templates. If the declaration of an explicit specialization for
   such a member appears in namespace scope, the member declaration shall
   be preceded by a template<> for each enclosing class template that is
   explicitly specialized.

It would not be necessary to say "if" above if that were the only 
place it could appear.

Nathan Myers
ncm@cantrip.org

Re: explicit specialization in non-namespace scope

[Mark Mitchell]

>>>>> "Nathan" == Nathan Myers <ncm@nospam.cantrip.org> writes:

    Nathan> I believe this is incorrect.  I find no such restriction.
    Nathan> In addition, in 14.7.3 - Explicit specialization
    Nathan> [temp.expl.spec] we have:

    Nathan>    -17- A member or a member template may be nested within
    Nathan> many enclosing class templates. If the declaration of an
    Nathan> explicit specialization for such a member appears in
    Nathan> namespace scope, the member declaration shall be preceded
    Nathan> by a template<> for each enclosing class template that is
    Nathan> explicitly specialized.

    Nathan> It would not be necessary to say "if" above if that were
    Nathan> the only place it could appear.

Since I implemented this, I'd better defend myself. :-)

    [temp.expl.spec] 
     
     An explicit specialization shall be declared in the namespace of
     which the template is a member, or, for member templates, in the
     namespace of which the enclosing class or enclosing class
     template is a member.  An explicit specialization of a member
     function, member class or static data member of a class template
     shall be declared in the namespace of which the class template
     is a member.  */

Also, note that:

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

is just like:

  template <class T>
  template <>
  void S<T>::f(int);

which is illegal, since S<T> isn't specialized.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: explicit specialization in non-namespace scope

[Oskar Enoksson]

>>>>> "Nathan" == Nathan Myers <ncm@nospam.cantrip.org> writes:

>> I believe this is incorrect.  I find no such restriction.
>> In addition, in 14.7.3 - Explicit specialization
>> [temp.expl.spec] we have:

>>    -17- A member or a member template may be nested within
>> many enclosing class templates. If the declaration of an
>> explicit specialization for such a member appears in
>> namespace scope, the member declaration shall be preceded
>> by a template<> for each enclosing class template that is
>> explicitly specialized.
>>
>> It would not be necessary to say "if" above if that were
>> the only place it could appear.
>
>Since I implemented this, I'd better defend myself. :-)
>
>    [temp.expl.spec] 
>     
>     An explicit specialization shall be declared in the namespace of
>     which the template is a member, or, for member templates, in the
>     namespace of which the enclosing class or enclosing class
>     template is a member.  An explicit specialization of a member
>     function, member class or static data member of a class template
>     shall be declared in the namespace of which the class template
>     is a member.  */

Thanks for all answers!

I can also report that Digital cxx rejects explicit member template
specializations.

To bad, it was very useful ...

/Oskar

Re: explicit specialization in non-namespace scope

[Nathan Myers]

Oskar Enoksson wrote:
> 
> >>>>> "Nathan" == Nathan Myers <ncm@nospam.cantrip.org> writes:
> 
> >> I believe this is incorrect.  I find no such restriction.
> >> In addition, in 14.7.3 - Explicit specialization
> >> [temp.expl.spec] we have:
> 
> >>    -17- A member or a member template may be nested within
> >> many enclosing class templates. If the declaration of an
> >> explicit specialization for such a member appears in
> >> namespace scope, the member declaration shall be preceded
> >> by a template<> for each enclosing class template that is
> >> explicitly specialized.
> >>
> >> It would not be necessary to say "if" above if that were
> >> the only place it could appear.
> >
> >Since I implemented this, I'd better defend myself. :-)
> >
> >    [temp.expl.spec]
> >
> >     An explicit specialization shall be declared in the namespace of
> >     which the template is a member, or, for member templates, in the
> >     namespace of which the enclosing class or enclosing class
> >     template is a member.  An explicit specialization of a member
> >     function, member class or static data member of a class template
> >     shall be declared in the namespace of which the class template
> >     is a member.  */
> 
> Thanks for all answers!

It's still not clear that the above text applies to the case mentioned.
"In the namespace of which the enclosing class is a member" is satisified
both outside and inside the class.  When it means to say "not in a class 
or in a block", it says "at namespace scope" or sometimes "in namespace 
scope"; these are changed from "at global scope" which is what it said
before we had namespaces.  "In the namespace of" does not imply "only
at namespace scope".

> I can also report that Digital cxx rejects explicit member template
> specializations.

Digital is a poor choice of compilers to check conformance.

> To bad, it was very useful ...

Anyhow, all is not lost.  You can specialize this member anyway,
even in egcs with bug added, just not as cleanly as you wanted:

  struct A {
    template <int I> inline int factorial();
  };
  template <> inline int A::f<0>() { return 1; }
  template <int I> inline void A::f<I>() { return f<I-1>() * I; }

Nathan Myers
ncm@cantrip.org

Re: explicit specialization in non-namespace scope

[Alexandre Oliva]

Nathan Myers <ncm@cygnus.com> writes:

>> >     An explicit specialization of a member
>> >     function, member class or static data member of a class template
>> >     shall be declared in the namespace of which the class template
>> >     is a member.  */

> It's still not clear that the above text applies to the case mentioned.
> "In the namespace of which the enclosing class is a member" is satisified
> both outside and inside the class.  When it means to say "not in a class 
> or in a block", it says "at namespace scope" or sometimes "in namespace 
> scope"

> Anyhow, all is not lost.  You can specialize this member anyway,
> even in egcs with bug added, just not as cleanly as you wanted:

>   struct A {
>     template <int I> inline int factorial();
>   };
>   template <> inline int A::f<0>() { return 1; }
>   template <int I> inline void A::f<I>() { return f<I-1>() * I; }

Unfortunately, this won't work if A is a template class, because,
AFAIK, in order to specialize A<...>::factorial<I>, A<...> must be
fully specialized.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: explicit specialization in non-namespace scope

[Mark Mitchell]

>>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes:

    >> Thanks for all answers!

    Nathan> It's still not clear that the above text applies to the
    Nathan> case mentioned.  "In the namespace of which the enclosing
    Nathan> class is a member" is satisified both outside and inside
    Nathan> the class.  When it means to say "not in a class or in a
    Nathan> block", it says "at namespace scope" or sometimes "in
    Nathan> namespace scope"; these are changed from "at global scope"
    Nathan> which is what it said before we had namespaces.  "In the
    Nathan> namespace of" does not imply "only at namespace scope".

I can see the sense in your interpretation.  (After all, besides
implementing the removal of this feature, I also implemented the
feature in the first place...)

But, do you think this is legal:

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

even though:

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

 template <class T>
 template <>
 void S<T>::f(int);

is not?  The standard says:

  In an explicit specialization declaration for a member of a class tem-
  plate or a member template that appears in namespace scope, the member
  template and some of its enclosing class templates may  remain  unspe-
  cialized,  except that the declaration shall not explicitly specialize
  a class member template if  its  enclosing  class  templates  are  not
  explicitly  specialized as well.

which doesn't say anything about specializations that are *not* in
namespace scope, which would therefore lead one to think this rule
does not apply.  So specializations of member templates in template
classes are in fact required to be inline?  Seems odd to me, although
I agree that the paragraph I quote adds credence to your point of view
about the legality of in-class specializations.  Perhaps I had better
get that code out of CVS, and reenable it.

    >> I can also report that Digital cxx rejects explicit member
    >> template specializations.

    Nathan> Digital is a poor choice of compilers to check
    Nathan> conformance.

But EDG is a good choice, and it too complains on specializations in
class scope.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: explicit specialization in non-namespace scope

[Nathan Myers]

Mark Mitchell wrote:
> 
> >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes: 
>     Nathan> It's still not clear that the above text applies to the
>     Nathan> case mentioned.  "In the namespace of which the enclosing
>     Nathan> class is a member" is satisified both outside and inside
>     Nathan> the class.  When it means to say "not in a class or in a
>     Nathan> block", it says "at namespace scope" or sometimes "in
>     Nathan> namespace scope"; these are changed from "at global scope"
>     Nathan> which is what it said before we had namespaces.  "In the
>     Nathan> namespace of" does not imply "only at namespace scope".
> 
> I can see the sense in your interpretation.  (After all, besides
> implementing the removal of this feature, I also implemented the
> feature in the first place...)

Yes, thank you, thank you!

> But, do you think this is legal:
> 
>   template <class T>
>   struct S {
>     template <class U>     void f(U);
>     template <>            void f(int);
>   };
> 
> even though:
> 
>  template <class T>
>  struct S {
>    template <class U>     void f(U);
>  };
> 
>  template <class T>
>  template <>
>  void S<T>::f(int);
> 
> is not?  The standard says:
> 
>   In an explicit specialization declaration for a member of a class tem-
>   plate or a member template that appears in namespace scope, the member
>   template and some of its enclosing class templates may  remain  unspe-
>   cialized,  except that the declaration shall not explicitly specialize
>   a class member template if  its  enclosing  class  templates  are  not
>   explicitly  specialized as well.
> 
> which doesn't say anything about specializations that are *not* in
> namespace scope, which would therefore lead one to think this rule
> does not apply.  So specializations of member templates in template
> classes are in fact required to be inline?  Seems odd to me, although
> I agree that the paragraph I quote adds credence to your point of view
> about the legality of in-class specializations.  Perhaps I had better
> get that code out of CVS, and reenable it.

Permitting only inline definitions of such specializations would 
indeed be perverse.  Incidentally, the paragraph (18) only addresses 
"declarations", not definitions, but the examples are of definitions.

I think it is clear that in nested specializations, only the inner
ones are allowed to be left unbound.  I don't think it was intended
to be a syntactic restriction, but a semantic one. 

>     >> I can also report that Digital cxx rejects explicit member
>     >> template specializations.
> 
>     Nathan> Digital is a poor choice of compilers to check
>     Nathan> conformance.
> 
> But EDG is a good choice, and it too complains on specializations in
> class scope.

Yes, I have written to them about this.

Nathan Myers
ncm@cantrip.org

Re: explicit specialization in non-namespace scope

[Matthias Mueller]

Nathan Myers writes:
 > Mark Mitchell wrote:
 > > 
 > > >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes: 
 > > 
 > >     Nathan> Digital is a poor choice of compilers to check
 > >     Nathan> conformance.
 > > 
 > > But EDG is a good choice, and it too complains on specializations in
 > > class scope.
 > 
 > Yes, I have written to them about this.

I would like to note that this depends very much on the compiler
version used. Digital cxx 6.x has improved much against 5.x. It is
based on a quite recent version of EDG. Has short compile times 
even with the new iostreams  and optimizes quite well. 

On alpha-osf-4.0c I can't compile my project with egcs-1.1 
(gives a strange syntax error I don't get on solaris-2.5.1)
but it works well with cxx. With the 19980906 snapshot it also works. 

At the moment compilers develop rapidly, we should be careful whenever
we judge a compiler and honour the effort of companies who try to
approach the standard with new releases.

Best regards,
	Matthias

-- 
+-----------------------------------------------------------------------+
| Matthias Mueller                    matthias@ica1.uni-stuttgart.de    |
|                         http://www.ica1.uni-stuttgart.de/~matthias    |
+-----------------------------------------------------------------------+
|        ICA 1, Pfaffenwaldring 27, D-70569 Stuttgart (Germany)         |
|           Tel. 49-(0)711/685-7606, Fax. 49-(0)711/685-3658            |
+-----------------------------------------------------------------------+

Re: explicit specialization in non-namespace scope

[Mark Mitchell]

>>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes:

    Nathan> Mark Mitchell wrote:
    >>  >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes:
    Nathan> It's still not clear that the above text applies to the
    Nathan> case mentioned.  "In the namespace of which the enclosing
    Nathan> class is a member" is satisified both outside and inside
    Nathan> the class.  When it means to say "not in a class or in a
    Nathan> block", it says "at namespace scope" or sometimes "in
    Nathan> namespace scope"; these are changed from "at global scope"
    Nathan> which is what it said before we had namespaces.  "In the
    Nathan> namespace of" does not imply "only at namespace scope".

    >>  I can see the sense in your interpretation.  (After all,
    >> besides implementing the removal of this feature, I also
    >> implemented the feature in the first place...)

I still haven't reimplemented this feature.  We've hashed out most of
the details, but I now remember one of the reasons I removed the
feature: it's not allowed by the grammar provided in the appendix to
the standard.  In particular, we have:

  member-declaration:
          decl-specifier-seqopt member-declarator-listopt ;
          function-definition ;opt
          ::opt nested-name-specifier templateopt unqualified-id ;
          using-declaration
          template-declaration

The only choices which could reasonably allow an explicit
specialization are `function-definition' and `template-declaration'.
The former, however, does not allow a template paramter list (and this
would be odd, since it would prohibit declaring a specialization
in-class, but defining it out-of-class).  The grammar for a
`template-declaration' specifically disallows an explicit
specialization, which is listed separately as
`explicit-specialization'.

What do you make of this?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: explicit specialization in non-namespace scope

[Nathan Myers]

Mark Mitchell wrote:
> 
> >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes:
> 
>     Nathan> Mark Mitchell wrote:
>     >>  >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes:
>     Nathan> It's still not clear that the above text applies to the
>     Nathan> case mentioned.  
> 
> I still haven't reimplemented this feature.  We've hashed out most of
> the details, but I now remember one of the reasons I removed the
> feature: it's not allowed by the grammar provided in the appendix to
> the standard.

OK, I give up.  If it would be an extension, then to me the 
most important extension to work out is template typedefs.

Nathan Myers
ncm@cygnus.com

Re: explicit specialization in non-namespace scope

[Nathan Myers]

Alexandre Oliva wrote:
> 
> Nathan Myers <ncm@cygnus.com> writes:
> > ... all is not lost.  You can specialize this member anyway,
> > even in egcs with bug added, just not as cleanly as you wanted:
> 
> >   struct A {
> >     template <int I> inline int factorial();
> >   };
> >   template <> inline int A::f<0>() { return 1; }
> >   template <int I> inline void A::f<I>() { return f<I-1>() * I; }
> 
> Unfortunately, this won't work if A is a template class, because,
> AFAIK, in order to specialize A<...>::factorial<I>, A<...> must be
> fully specialized.

This can be got around by defining a helper function template specialized
to call a nontemplate member.  The extra declarations are unpleasant 
but need not be exposed to users.

Nathan Myers
ncm@cantrip.org