Re: Help with a compile problem
On May 31, 2:08 am, Pete C <5gv7rq...@sneakemail.com> wrote:
On May 30, 10:30 pm, derek.goo...@grog.net wrote:
Not sure I understand. I'm not copying anything, so what exactly is
it that's wrong? That the class Foo is actually non-copyable by
design, and since there is no copy that I can see, the compiler should
not require a public copy ctor just because I'm using a temporary
object.
Yes it should - in fact, it *has* to require an accessible copy ctor.
Your expression "Foo()" is an rvalue (section 3.10.6 of the standard).
When you pass it to your operator<<, you are binding an rvalue to a
const reference (covered by section 8.5.3 of the standard). In this
case the compiler is given 2 options by the standard:
1) bind the reference directly to the rvalue, or
2) construct a new temporary object from the the rvalue object, and
bind the reference to the temporary object.
As it happens, g++ chooses option 1. But the standard says "The
constructor that would be used to make the copy shall be callable
whether or not the copy is actually done." And you have made yours
private.
So g++ is correct to complain, and the other compilers are wrong to
accept your code. FWIW I don't understand the rationale for option (2)
above, but there you have it.
It's related to the lifetime of temporaries. Consider something
like the following:
struct B {} ;
struct A { B b ; } ;
A f() ;
void
g()
{
B const& b = f().b ;
// uses b...
}
According to the standard, the lifetime of the object bound to
the reference in g is until the end of the function. But the
lifetime of the A object returned by f() must end at the end of
teh full expression. And the only way to destruct the A object
without destructing the B object bound to b is by making a copy.
(Both G++ and VC++ do copy in the above case, as required by the
standard.)
Presumably, the authors of the standard didn't want to make
special cases, and describe in full detail when and when not the
copy would occur, so the simply made it up to the implementation
in all cases. And required the copy constructor to be
accessible just in case.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34