On Wed, Feb 12, 2014 at 8:55 AM, John McCall <[email protected]> wrote:
> On Feb 10, 2014, at 12:39 PM, Richard Smith <[email protected]> > wrote: > > On 10 February 2014 09:32, John McCall <[email protected]> wrote: > >> On Feb 9, 2014, at 6:17 PM, Richard Smith <[email protected]> >> wrote: >> >> On 9 February 2014 05:37, Hubert Tong <[email protected]> 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. > > > Inaccessible does imply non-public, but accessibility in general is > context-sensitive. > > Are you asking for the ABI rule to actually be "non-public, non-trivial, > or deleted"? I agree that that's what the standard is requesting, because > it's the only way we can guarantee at the point of declaration of a > function that all callers will be able to access the special member. > However, it's not the current practice of any compiler, probably because > we generally try quite hard to prevent access control from affecting the > ABI, e.g. because it seems unfortunate for things like "#define private > public" to actually break binary compatibility. (I'll grant that it's > legal under the standard, and it might also already affect the ABI in > corner cases by making a base class suddenly POD.) > > John. > I agree 'inaccessible' is context dependent, and it is a good feature that the ABI does not try to hard to reflect access specifiers.
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
