[cxx-abi-dev] deleted functions, implicit move constructors, and the ABI

[David Vandevoorde]

On Jun 22, 2010, at 11:22 AM, Jason Merrill wrote:

> I thought I remembered Lawrence sending mail to the list about deleted functions a while back, but I don't see it now.  But in N3053 he notes that ABIs may want to treat deleted functions as trivial in some situations.
> 
> There are two places in the ABI that deal with triviality:
> 
> 1) Array new cookies.  If the destructor is deleted, we won't ever call it, so it doesn't require a cookie.
> 
> 2) Parameter/return value passing.  Currently if the copy constructor or destructor is non-trivial, we pass and return by invisible reference. We might as well treat a deleted dtor as trivial in this case as well, though it's not a very interesting case.


Actually, I'd prefer not to introduce a divergence from the standard notion of trivial, and therefore "deleted destructors" would be nontrivial.


> We definitely don't want to change the C++98-compatible cases (implicit trivial, implicit non-trivial, user-provided).  But what if the copy constructor is deleted, or there is no copy constructor because it's suppressed by a user-declared move constructor?
> 
> It seems natural to change "a non-trivial copy constructor or destructor" to "a non-trivial, non-deleted copy constructor, move constructor or destructor".
> 
> OTOH, that would make changing a no-copy class's copy constructor or destructor from private and undefined to deleted an ABI change,


Right.  Again, I'd prefer to just keep with what falls out of the standard notion of "trivial copy constructor" (a deleted copy constructor is nontrivial, and hence the associated class is passed by invisible reference).


> so perhaps we should treat deleted functions as non-trivial for this purpose (and array new cookies).  I am ambivalent on this point.
> 
> But we definitely need to do something about classes with a move constructor and no copy constructor.  I think we want to add "move constructor" to the list as above, for consistency with the definition of "trivially copyable".


Right.  Below is an e-mail I posted a while back about that.


	Daveed


> 
> Thoughts?
> 
> Jason



	From: 	David Vandevoorde <daveed at edg.com>
	Subject: 	[cxx-abi-dev] Transfer modes for parameters and return values
	Date: 	June 3, 2009 4:59:51 PM EDT
	To: 	cxx-abi-dev at codesourcery.com

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.)

	Daveed