[cxx-abi-dev] Transfer modes for parameters and return values

[Richard Smith]

We also have a minor ABI incompatibility between C++03 and C++11 due to the
change to use the selected constructor when determining triviality of a
copy constructor:

struct A {
  template<typename T> A(T&);
};
struct B {
  mutable A a;
};

B has a trivial copy constructor in C++03, but a non-trivial copy
constructor in C++11.

On Tue, Nov 27, 2012 at 12:17 PM, Richard Smith <richardsmith at google.com>wrote:

> On Tue, Nov 27, 2012 at 5:47 AM, Jason Merrill <jason at redhat.com> wrote:
>
>> On 11/26/2012 04:09 PM, Richard Smith wrote:
>>
>>> Suggestion for core language:
>>>
>>
> This is probably best discussed further on the core reflector.
>
>
>>  When an object of class type C is passed to or returned from a function,
>>> if C has a trivial, accessible copy or move constructor that is not
>>>
>>
>> I don't think we want to check accessibility; the calling convention for
>> a type needs to be the same no matter where it's called from, and I think
>> it's fine for the compiler to use a private trivial copy constructor that
>> isn't deleted.
>
>
> The suggested ABI change requires a public constructor, not just an
> accessible one. I don't think it's OK to synthesize calls to private
> trivial copy constructors; such things might just be implementation details
> of the class:
>
> class A {
> public:
>   enum Kind { ... };
>   A(const A &a, Kind k) : A(a) {
>     if (p == &a) p = this;
>     this->k = k;
>     clog() << "Created A at address " << this << endl;
>   }
> private:
>   // Synthesize a copy constructor for use *only* in our own constructors
>   A(const A&) = default;
>   void *p;
>   Kind k;
>   // ...
> };
>
> I would be fine with restricting the core language change to only apply to
> classes with public copy/move constructors.
>
>
>>  deleted, and has no non-trivial copy constructors, move constructors,
>>>
>>
>> Incidentally, if we're making this latitude explicit, we don't
>> necessarily need to involve move constructors at all.  I don't have much of
>> an opinion either way.
>
>
> There aren't many cases which would be affected by this, but some form of
> owning wrapper for a value (with a deleted copy constructor, a trivial move
> constructor and a trivial destructor) seems plausible, and there seems to
> be no good reason to require it to be passed by address, so I'm weakly in
> favor of handling move constructors here too.
>
>
>>  nor destructors, implementations are permitted to perform an additional
>>> copy or move of the object using the trivial constructor (even if it
>>> would not be selected by overload resolution to perform a copy or move
>>> of the object). [Note: This latitude is granted to allow objects of
>>> class type to be passed to or returned from functions in registers --
>>> end note]
>>>
>>
>> I think when we added implicit move constructors we decided against
>> talking about "copy or move" of an object, since moving is a special case
>> of copying.
>
>
> I picked this wording to match the "A class object can be copied or moved
> in two ways" in [class.copy]p1, but this seems fine to me either way.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20121206/4b61d296/attachment.html>