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

David Vandevoorde daveed at edg.com
Fri Jun 5 00:49:42 UTC 2009


On Jun 4, 2009, at 5:34 PM, Jason Merrill wrote:

> David Vandevoorde wrote:
>> Note that if I'm correct, there is already a bug in the ABI because  
>> a class like:
>>    struct S {
>>      S(int);
>>    };
>>    void f(S);
>> today is passed "by trivial copy" in the function f (according to  
>> the ABI).  However, my understanding is that in
>>    int main() {
>>      f(3);
>>    }
>> no copy constructor should be called (even "conceptually") for the  
>> argument transfer (i.e., despite it being a "copy initialization"  
>> it behaves like a "direct initialization).
>
> No.  To copy-initialize the parameter of f, we first convert 3 to S  
> using the constructor, then construct the parameter using that  
> temporary S as an argument, which invokes the (trivial) copy  
> constructor.
>
> However, I think you are right about your earlier move constructor  
> example: since the argument S() has type S already, we don't do the  
> two-step initialization, so we can't do a (trivial) copy afterward.


Ah yes, that's right.

> This line of reasoning also applies to any other constructor which  
> can be called with an argument of the that class or a derived class,  
> but I think before rvalue references it was impossible to write an  
> alternative constructor which would ever be preferred over the  
> implicitly declared copy constructor for an argument of that class  
> type.


How about:

	struct D;
	struct B {
	  B(D&);
	};
	struct D: B {} d;
	void f(B);
	int main() {
	  f(d);
	}

I think this exercise the "derived class" case, and so if I understand  
correctly it requires a direct-initialization-like approach for B.   
However, since B has a trivial copy constructor, the transfer mode of  
f(B) doesn't allow for that.

(I think that's contrived enough that even if this shows an ABI bug it  
doesn't require a fix per se.)

>
> So now I think we do need your suggested change.


Thanks.  I'll try to write that up too.  Some other ideas in this area  
have occurred to me and I'll bring them up on the WG21 reflector.  It  
may be that the outcome of that affects the ABI spec.

	Daveed




More information about the cxx-abi-dev mailing list