In article <9524503.22797@mulga.cs.mu.OZ.AU> you write:
>gcato@st6000.sct.edu (Vaughn Cato) wrote:
>>template <class T = int> class A;
>>
>>void f() {
>>  A<> *p1; // The legal way to default the argument
>>  A *p2;   // Syntax error
>>}
>
> template <int i = 42> struct A { A(int = 0) {} };
> foo(*new A<0>(0));
>  // should that be parsed as `foo((*new A) < 0) > 0)'??

I see how use with the new operator could cause an ambiguity.  If the form
without <> was treated as as a secondary syntax I don't believe it would be
a problem though:

template <int i = 42> class A;
class B;

  new A<0>(0);  /* Interpreted as usual. */
  new A(0);     /* Interpreted as new A<0>(0) since it would be a syntax
                   error otherwise */
  new B<0>(0);  /* Interpreted as ((new B)<0)>0 as usual */
  new B(0);     /* Interpreted as usual. */

Of course, this is messy.  It is basically the same as how the declaration/
constructor call ambiguity is resolved.

  Until Later,
  Vaughn Cato (gcato@st6000.sct.edu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

gcato@st6000.sct.edu (Vaughn Cato) wrote:
>template <class T = int> class A;
>
>void f() {
>  A<> *p1; // The legal way to default the argument
>  A *p2;   // Syntax error
>}

This has been discussed by the committee - I think the conclusion was that
allowing the simpler syntax would cause some problems, but I don't remember
off-hand what those problems were.

Perhaps the problem is ambiguity between `<' as less-than and `<' as
the start of a template angle bracket pair, e.g.

 template <int i = 42> struct A { A(int = 0) {} };
 foo(*new A<0>(0));
  // should that be parsed as `foo((*new A) < 0) > 0)'??

?

--
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

gcato@st6000.sct.edu (Vaughn Cato) wrote:
>I am curious as to the reasoning behind disallowing the use of a template
>name as a synonym for a template id with no template parameters:
>
>template <class T = int> class A;
>
>void f()
>{
>  A<> *p1; // The legal way to default the argument
>  A *p2;   // Syntax error
>}

If the latter was allowed, it would be ambiguous if a non-templated class A
existed.

If we allowed it anyway and just told the compiler to complain about
ambiguities, then the above code would break the moment an unrelated class A
visible to this function was created... bad side effect.

>This parallels with
>the function call syntax, which requires ()'s to be used even when no
>actual parameters are passed.

Exactly, for similar reasons: it would be odd if your code suddenly broke
(became ambiguous and uncompilable) if someone added a variable that happened
to have the same name as a function you're using... without (), it wouldn't be
possible to differentiate the two.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
In article <199508241251.IAA03008@gold.interlog.com>,
Herb Sutter <herbs@interlog.com> wrote:
>gcato@st6000.sct.edu (Vaughn Cato) wrote:
>>I am curious as to the reasoning behind disallowing the use of a template
>>name as a synonym for a template id with no template parameters:
>>
>>template <class T = int> class A;
>>
>>void f()
>>{
>>  A<> *p1; // The legal way to default the argument
>>  A *p2;   // Syntax error
>>}
>
>If the latter was allowed, it would be ambiguous if a non-templated class A
>existed.

Is it really so?

[temp.names]/6 states:

"The name of a class template shall not be declared to refer
to any other template, class, function, object, enumeration, enumerator,
namespace, value or type in the same scope. ..."

That is, there can be no non-templated class A. And if it were allowed,
there would be a workaround for the problem, namely:
   typedef A<> A;

But as I understand it, this is not allowed.

>Exactly, for similar reasons: it would be odd if your code suddenly broke
>(became ambiguous and uncompilable) if someone added a variable that happened
>to have the same name as a function you're using... without (), it wouldn't
>be possible to differentiate the two.

I can't understand your point. You can't have a function and a variable
with the same name anyway. The reason for not allowing function calls
without () is (IMHO it's a shame) that you couldn't differentiate
between the function and its address (since function's name without ()
means its address). Consider:

typedef void (*FPTR)(void);
FPTR f();

void main()
{
  FPTR ptr = f; // call f and use return value to initialize ptr OR
                // initialize ptr with f (= type mismatch)
}

If I had the choice of re-designing the language, I would have disallowed
the bare function name to be used as a pointer to the function and
allowed the calls to functions without ().

But this problem doesn't apply to type names, and especially not
to class template parameters.

Or am I missing something?
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]