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