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

[Lawrence Crowl]

On Wed, Jun 3, 2009 at 4:59 PM, David Vandevoorde <daveed at edg.com> wrote:
> On Jun 3, 2009, at 5:23 PM, Lawrence Crowl wrote:
>> On 6/3/09, David Vandevoorde <daveed at edg.com> wrote:
>>>
>>> Hello again,
>>>
>>> In 3.1.1 and 3.1.4, the ABI specifies that "by value" class type
>>> parameters
>>> and class type return values are passed via the address of a reference if
>>> the class type has
>>>       (a) a nontrivial destructor, or
>>>       (b) a nontrivial copy constructor.
>>>
>>> Should we now also add to that:
>>>       (c) a (nontrivial) move constructor
>>> ?
>>>
>>> (There is currently no notion of "trivial move constructor", but I think
>>> there are suggestions to introduce that in the future.)
>>
>> I'm not sure I can predict the binary consequences of such a notion
>> until it is actually defined.  So, I would rather wait until then.
>
> It doesn't really have to be defined formally: A constructor for class X
> whose first parameter has type
>        X cv-quals&&
> and whose other parameters have a default argument or are the ellipsis
> parameter.  Such a constructor can be preferred over the trivial copy
> constructor for "rvalue copying" (i.e., moving) purposes.

I think I am confused.  I have two comments, and I don't know which
applies.

Since we don't know what a 'trivial' move constructor is, how do we know
how it might be implemented, and therefore whether it affects the ABI?

The choice of constructor isn't part of the ABI, but of the semantics of
the program.  Once the semantics are picked, the ABI keeps it stable, so
I don't see how any preference for the move constructor would require
us to modify how we represent parameters for copy construction.

-- 
Lawrence Crowl