This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.0.1 & C++ ABI issues
- To: gdosreis at sophia dot inria dot fr (Gabriel Dos_Reis)
- Subject: Re: gcc 3.0.1 & C++ ABI issues
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Mon, 6 Aug 2001 14:55:56 -0700 (PDT)
- Cc: jason_merrill at redhat dot com (Jason Merrill), nathan at codesourcery dot com (Nathan Sidwell), mark at codesourcery dot com (Mark Mitchell), gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org)
> | Are you thinking of this:
> |
> | inline A f (A a) { return a; }
> |
> | int main ()
> | {
> | A a1 = f (A ());
> | }
> |
> | ? Currently, this would involve two constructor calls, the default ctor to
> | construct the parameter and the copy ctor to initialize 'a1'. It seems
> | reasonable to elide the copy ctor in this case,
>
> Most people expect that.
>
> | but IMO the standard doesn't allow it.
>
> Really? I think it is allowed: 12.8/15
>
> Whenever a temporary class object is copied using a copy constructor,
> and this object and the copy have the same cv-unqualified type, an
> implementation is permitted to treat the original and the copy as two
> different ways of referring to the same object and not perform a copy
> at all, even if the class copy constructor or destructor have side
> effects. [...]
Right. Copy constructors can always be eliminated. The only case where the
copy constructor cannot be overlooked is where the caller does not have
permission to invoke the copy constructor. Then the code must be
rejected, even though the compiler would not call the copy constructor.