I'm sorry if this is point has been dealt with elsewhere, but surely
the statement

 myClass(x);

in

 myClass x(ctor,args);
 f() { myClass(x); doStuff(x); }

is ambiguous.  It could either construct a temporary object myClass from
a variable x, or it could declare a new myClass x.  My compiler treats
this as a declaration.  There may be circumstamces where either
behaviour would be required.  How is this conflict resolved in the
standard?  As a side note, this seems like an irritating inconsistency
in the language.

-- Calum



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 3122B930@hermes.cam.ac.uk, "C. Grant" <camg100@hermes.cam.ac.uk> writes:
>I'm sorry if this is point has been dealt with elsewhere, but surely
>the statement
>
> myClass(x);
>
>in
>
> myClass x(ctor,args);
> f() { myClass(x); doStuff(x); }
>
>is ambiguous.  It could either construct a temporary object myClass from
>a variable x, or it could declare a new myClass x.  My compiler treats
>this as a declaration.

It is in principle ambiguous, but the rule in C++ has always been
that the ambiguity between an expression-statement and a declaration
is resolved as a declaration.

See the ARM section 6.8 "Ambiguity resolution" (p 93), which is the
same as the draft standard section 6.8.


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



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

C. Grant wrote:

> I'm sorry if this is point has been dealt with elsewhere, but surely
> the statement
>         myClass(x);
> in
>        myClass x(ctor,args);
>         f() { myClass(x); doStuff(x); }
> is ambiguous.  It could either construct a temporary object myClass from
> a variable x, or it could declare a new myClass x.  My compiler treats
> this as a declaration.  There may be circumstamces where either
> behaviour would be required.  How is this conflict resolved in the
> standard?  As a side note, this seems like an irritating inconsistency
> in the language.
>

Letting others direct you to a more up-to-date reference, nonetheless you may
care tolook at the ARM section 8.1.1
Basically, if it can be taken as a declaration, it is taken that way.
HTH
Mungo Henning



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

C. Grant wrote:
>
> I'm sorry if this is point has been dealt with elsewhere, but surely
> the statement
>
>         myClass(x);
>
> in
>
>         myClass x(ctor,args);
>         f() { myClass(x); doStuff(x); }
>
> is ambiguous.  It could either construct a temporary object myClass from
> a variable x, or it could declare a new myClass x.  My compiler treats
> this as a declaration.  There may be circumstamces where either
> behaviour would be required.  How is this conflict resolved in the
> standard?  As a side note, this seems like an irritating inconsistency
> in the language.

If it can be parsed as declaration, it is a declaration.

The cleanest solution to get a temporary is to make a local scope and
name the new object:

void f()
{
  { myClass temporary(x); }
  doStuff(x);
}

However, as the compiler can prove that the temporary is not used
any more (named or not), it is allowed to discard the copy
construction/destruction of it anyway. So it's a good idea not to
rely on this construct.