While the issue is up: I would be interested in knowing why the draft requires
empty angle brackets in the case of an template with a fully defaulted
parameter list. As it is possible to disambiguate between template-id and
template-class-name inside the template definition (X is equal to X<...>),
I fail to see why this can't be done generally.

The only subtlety I'm aware of is that the template-id would mean something
different when used inside the template definition. Clearly, it would still
imply the 'current' arguments there, not the default. Guess that wouldn't be
too much of a problem, neither for the compiler, nor for the human reader:

 template <class T = U>
 class X
 {
  X(); // X<T> (as always)
 };

 X x; // X<U> here and anywhere else


I think allowing to discard the empty brackets is useful to write classes
which have some default or main behaviour but can be explicitly specified
to act differently on demand. The user didn't have to care that they are
in fact templates. For example, instead of having the basic_string
template and a typedef to string, we could have a single string template
which defaults to char.

Was there a problem with it or was such behaviour explicitly undesired?


 - Andreas Rossberg

The more you read the draft, the more confused you get.  Maybe I need to
hire a few language lawyers to interpret this stuff...

Anyway, take this example:
// 14.1
//
// 3 A template-id that names a defined template class can be used exactly
// like the names of other defined classes.
//

template <class T>
struct A {
  T at;
  A() { }
  ~A() { };
};

typedef A<int> Aint;

static char buf[sizeof(Aint)];

main()
{
  A<int>* ap = new (buf) A<int>();

  ap->A<int>::~A<int>();        // 1
  ap->~A<int>();                // 2
  ap->~Aint();                  // 3
  ap->Aint::~Aint();            // 4

  // ap->A<int>::~A();          // 5 illegal?
  // ap->~A();                  // 6 illegal?
  return 0;
}

My understanding of 14.1 p3 leads me to believe cases 1-4 above should
all should work fine.  Cases 5 and 6 are anyone's guess.  Of course,
none of the compilers I've tried will compile 1-4, most don't like 2 or 4,
and most do like 5.

First off, where do we look to find out which are legal?  That is IF
the draft mentions which of these are legal anywhere.

12.4 talks about the explicit call to the destructor and gives examples.
p->X::~X() and p->int::~int() are shown.  Why are these qualified?  Is this
required?  And if so where is it hiding out?  p->~int() and p->~X() make
as much sense to me....

Does anyone else find that there are examples of things (such as explicit
call of a destructor) instead a definitions?

In article ou9@zip.eecs.umich.edu, mrice@quip.eecs.umich.edu (Michael Rice) writes:
>// 14.1
>//
>// 3 A template-id that names a defined template class can be used exactly
>// like the names of other defined classes.
>//
>
>template <class T>
>struct A {
>  T at;
>  A() { }
>  ~A() { };
>};
>
>typedef A<int> Aint;
>
>static char buf[sizeof(Aint)];
>
>main()
>{
>  A<int>* ap = new (buf) A<int>();
>
>  ap->A<int>::~A<int>();        // 1
>  ap->~A<int>();                // 2
>  ap->~Aint();                  // 3
>  ap->Aint::~Aint();            // 4
>
>  // ap->A<int>::~A();          // 5 illegal?
>  // ap->~A();                  // 6 illegal?
>  return 0;
>}

1: Clearly OK.

2: Also OK, but some compilers have historically had problems parsing t->~T()
as opposed to t->T::~T(). Such problems, if any, might carry over
into template versions.

3,4: I don't read the standard as allowing a typedef name to stand for
the name of a constructor or destructor. It is explicitly disallowed
when declaring those functions in the class, and it seems to me that
other wording implies it is not allowed elsewhere. I'm told this is
still under discussion.

5,6: Clearly ill-formed. "A" is not the name of any type when used
outside the scope of the class template. That is, inside the template
you can refer to A or A<T> equivalently. Outside the template you can
refer to a type A<SomeParticularType>, but not to just A.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article skv@engnews2.Eng.Sun.COM, clamage@Eng.Sun.COM (Steve Clamage) writes:

After a conversation with John Spicer, I have to retract some of my comments.

>In article ou9@zip.eecs.umich.edu, mrice@quip.eecs.umich.edu (Michael Rice) writes:
>>// 14.1
>>//
>>// 3 A template-id that names a defined template class can be used exactly
>>// like the names of other defined classes.
>>//
>>
>>template <class T>
>>struct A {
>>  T at;
>>  A() { }
>>  ~A() { };
>>};
>>
>>typedef A<int> Aint;
>>
>>static char buf[sizeof(Aint)];
>>
>>main()
>>{
>>  A<int>* ap = new (buf) A<int>();
>>
>>  ap->A<int>::~A<int>();        // 1
>>  ap->~A<int>();                // 2
>>  ap->~Aint();                  // 3
>>  ap->Aint::~Aint();            // 4
>>
>>  // ap->A<int>::~A();          // 5 illegal?
>>  // ap->~A();                  // 6 illegal?
>>  return 0;
>>}
>
>1: Clearly OK.
>
>2: Also OK, but some compilers have historically had problems parsing t->~T()
>as opposed to t->T::~T(). Such problems, if any, might carry over
>into template versions.
>
>3,4: I don't read the standard as allowing a typedef name to stand for
>the name of a constructor or destructor. It is explicitly disallowed
>when declaring those functions in the class, and it seems to me that
>other wording implies it is not allowed elsewhere. I'm told this is
>still under discussion.
>
>5,6: Clearly ill-formed. "A" is not the name of any type when used
>outside the scope of the class template. That is, inside the template
>you can refer to A or A<T> equivalently. Outside the template you can
>refer to a type A<SomeParticularType>, but not to just A.

5 and 6 are NOT "clearly ill-formed."

5 should be OK, since within the scope of a template class, the un-decorated
name of the class may be used. The prefix "A<int>::" puts us in that scope.

It isn't completly clear whether the prefix "ap->" will also allow us to
use "A" as the name of the class, so 6 might or might not be OK.

I think it is clear that the draft needs some more work in specifying
what names can be used in these circumstances.

---
Steve Clamage, stephen.clamage@eng.sun.com