On Sunday 03 July 2005 02:26 pm, Dirk Jagdmann wrote:
> The behaviour of gcc is standard compliant, since an assignment in the
> same statement as a variable declaration is always treated by the copy
> constructor.
This is what I expected, yet the copy constructor wasn't called. The copy
constructor call was optimized away and -fno-elide-constructors will turn off
this optimization.
> The mentioned gcc switch
> -fno-elide-constructors will work, but on other compilers you'll have
> the same behaviour again.
Hmm, I get the feeling that the first part of your message is not as you
intended.
The point is that if I make the copy constructor private,
I get a compile error:
error: `Foo::Foo(const Foo&)' is private
Which suggests that the copy constructor should be called in statements like:
A a = 2;
So, I'm wondering what the standard actually says. If A a =2; always means
A a(2); then I don't see why you would need the copy constructor to be public.
I've found the following in the comp.lang.c++.moderated archive:
"TITLE: direct and copy initialization
UPDATE: In the last case ("T t3 = u;") the
user-defined conversion and the T copy constructor must
both be called. In CD2 and until the London meeting in
July 1997, the compiler was permitted to elide the copy
constructor call as long as the copy constructor could
have been called (i.e., was accessible). Since July
1997 and in the final draft standard, the compiler may
not make this optimization to elide the copy
constructor call."
To me this says, that I -fno-elide-constructors should be the default
behavior. Which it isn't (at least for gcc 3.3.4).
best,
Jeroen
--
Kile -- KDE Integrated LaTeX Environment
http://kile.sourceforge.net
