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

[Richard Smith]

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/20121127/9518aff9/attachment.html>