On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely via cfe-commits < cfe-commits@lists.llvm.org> wrote:
> On 8 February 2016 at 18:31, H.J. Lu <hjl.to...@gmail.com> wrote: > > On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely <jwakely....@gmail.com> > wrote: > >> On 8 February 2016 at 18:26, Jonathan Wakely <jwakely....@gmail.com> > wrote: > >>> On 8 February 2016 at 17:58, H.J. Lu wrote: > >>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely < > jwakely....@gmail.com> wrote: > >>>>>>> A type is a standard-layout type, or it isn't. > >>>>>> > >>>>>> How about "An empty record is standard-layout Plain Old Data (POD) > >>>>>> type and ..."? > >>>>> > >>>>> That's redundant, all POD types are standard-layout types. > >>>>> > >>>> > >>>> Apparently, not all standard-layout types are POD types. GCC has > >>>> > >>>> /* Nonzero means that this class type is not POD for the purpose of > layout > >>>> (as defined in the ABI). This is different from the language's > POD. */ > >>>> CLASSTYPE_NON_LAYOUT_POD_P > >>>> > >>>> and > >>>> > >>>> /* Nonzero means that this class type is a non-standard-layout > class. */ > >>>> #define CLASSTYPE_NON_STD_LAYOUT > >>>> > >>>> They aren't the same. > >>>> > >>>> struct A { }; > >>>> struct B { }; > >>>> struct C : A, B { }; > >>>> > >>>> C is a standard-layout type, but not a standard-layout POD type. > >>> > >>> As the comment says, "POD for the purposes of layout" is different > >>> from the language's POD. All standard-layout types are POD types > >>> according to the language. > >>> > >>> So when you previously had "POD for the purposes of layout" that was > >>> at least partially clear that you meant something other than what the > >>> language means. But as pointed out, using a GCC-specific term is not > >>> ideal. > >>> > >>> When you changed it to "POD for the purpose of standard-layout" that > >>> became a completely meaningless term. Where is that defined? > >>> > >>> Your next suggestion was "standard-layout Plain Old Data (POD)" which > >>> is even worse, now you're using two terms defined by the C++ language, > >>> but you mean something different. > >>> > >>> When you mean something that is the same as the language (like "class > >>> type") it makes sense to use the same term. > >>> > >>> When you mean something that is not the same as the language (like > >>> "POD") it makes sense to use a different term, or clearly define how > >>> you are using it. > >> > >> To be clear: it's really confusing to take two terms defined by the > >> language, "POD" and "standard-layout", and smash them together to mean > >> something new. > >> > >> According to your proposal, struct C is a POD type, and a > >> standard-layout type, but not a "standard-layout POD type". That's > >> just crazy. > > > > Can you suggest a better wording? > > I don't know what the definition of "POD for the purposes of layout" > is, but if I was trying to define a better name for it I would start > by trying to understand how it is specified, instead of just throwing > existing terms together. "POD for the purpose of layout" is defined in the Itanium C++ ABI here: http://mentorembedded.github.io/cxx-abi/abi.html#definitions > Another issue, if I define > > > > 1. "class type". A class type is a structure, union or C++ class. > > 2. "empty class type". An empty class type is: > > a. A class type without member. Or > > b. A class type with only members of empty class types. Or > > c. An array of empty class types. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Will it confuse people? > > Yes :-) > > But that was already confusing when you called it an "empty > collection" because an array isn't a collection. > > If I understand correctly, your proposal says that given: > > struct A { }; // empty class type > typedef A A2[2]; // array of empty class types > > struct B { A a[2]; }; // empty record? > > struct B is an empty record ... is that right? > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits