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

[Lawrence Crowl]

On 6/22/10, David Vandevoorde <daveed at edg.com> wrote:
> 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,

I think programmers would prefer to make that code change without
changing their ABI.  In the absence of other significant ABI changes,
I believe we should let them.

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

The standard currently says:

  A trivially copyable class is a class that:
    -- has no non-trivial copy constructors (12.8),
    -- has no non-trivial move constructors (12.8),
    -- has no non-trivial copy assignment operators (13.5.3, 12.8),
    -- has no non-trivial move assignment operators (13.5.3, 12.8), and
    -- has a trivial destructor (12.4).

A strict correspondence would use the same wording for value
parameters, but omitting the two bullets on assignment operators.
I don't think that wording would change the ABI for any C++03 code,
but would for C++0x code that used =default.  In that situation,
we probably do want the "no non-trivial" wording.

> Right.  Below is an e-mail I posted a while back about that.
>
>        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.)

And it was introduced.  See 12.8/13.

-- 
Lawrence Crowl