[cxx-abi-dev] The magic of uncalled copy constructors; documenting the bug

Richard Smith richardsmith at google.com
Mon Feb 10 20:39:28 UTC 2014


On 10 February 2014 09:32, John McCall <rjmccall at apple.com> wrote:

> On Feb 9, 2014, at 6:17 PM, Richard Smith <richardsmith at google.com> wrote:
>
> On 9 February 2014 05:37, Hubert Tong <hstong at ca.ibm.com> wrote:
>
>> Core Issue 1590 mentions that the trivial copy or move constructor should
>> be non-deleted and accessible.
>> Replacing the pair of copy constructors below with private, deleted copy
>> and move constructors seems to make GCC avoid the "magic" copy, but not
>> Clang.
>> Which compiler has the preferred behaviour?
>>
> I think GCC does, whereas Clang obeys the current description of the ABI.
>
> Under the current wording of core issue 1590, we're not allowed to perform
> a 'trivial' copy here. I think we should update the ABI document (in
> 3.1.1/1) to make this work (perhaps something equivalent to replacing
> "non-trivial" with "non-trivial, non-public, or deleted" each time it
> occurs).
>
>
> gcc’s rule appears to just be “non-trivial or deleted”, which I think is
> reasonable for the ABI to adopt.  Would you like to write up a proposal for
> that?
>

Sure.


> “Accessible” does not mean “public”.  That’s a standards bug: we need to
> be able to decide the ABI signature of a function at its point of
> declaration, not have it be dependent on whether there exist (or might
> exist) calls to it which would not be allowed to use a privately-defaulted
> trivial copy constructor.
>

I don't see anything wrong with the standard here. Inaccessible implies
non-public for these members (because they're not inherited from a base
class), so the ABI can look for a public special member where the standard
says any accessible special member is permitted to be called.

Note that the pre-C++11 idiom for suppressing the copy-constructor would
> also make it non-trivial, so that’s okay.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140210/0c5c5ffc/attachment.html>


More information about the cxx-abi-dev mailing list