On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>
>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith <rich...@metafoo.co.uk> 
>>>>> wrote:
>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> >>
>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely 
>>>>> >> <jwakely....@gmail.com>
>>>>> >> wrote:
>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote:
>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI 
>>>>> >> >> here:
>>>>> >> >>
>>>>> >> >>   http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>>>>> >> >
>>>>> >> > Thanks. So there's no problem using "POD for the purposes of layout",
>>>>> >> > and the change to "POD for the purpose of standard-layout" was
>>>>> >> > unnecessary and just confused things.
>>>>> >>
>>>>> >> Here is the revised proposal:
>>>>> >>
>>>>> >> 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
>>>>> >
>>>>> >
>>>>> > (a) is a special case of (b).
>>>>> >
>>>>> >>    c. An array of empty class types.
>>>>> >
>>>>> >
>>>>> > It seems confusing to call an array a class type. Instead, how about:
>>>>> >
>>>>> >   2. An empty type is either an array of empty types or a class type 
>>>>> > where
>>>>> > every member is of empty type.
>>>>> >
>>>>> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>>>>> >>    purposes of layout and
>>>>> >>    a. A class type without member.  Or
>>>>> >>    b. A class type with only members of empty class types.
>>>>> >
>>>>> >
>>>>> > (a) is a special case of (b).
>>>>> >
>>>>> >> 4. No memory slot nor register should be used to pass or return an 
>>>>> >> object
>>>>> >> of empty record.
>>>>> >
>>>>> >
>>>>> > Objects of array type are never passed or returned (but if through some
>>>>> > language extension they were, we'd want this rule to apply). So you 
>>>>> > don't
>>>>> > need rule 3 and this can be just:
>>>>> >
>>>>> >  3. No memory slot nor register should be used to pass or return an 
>>>>> > object
>>>>> > of empty type.
>>>>>
>>>>> Thanks very much for your inputs.  Here is the proposal:
>>>>>
>>>>> 1. "class type".  A class type is a structure, union or C++ class.
>>>>> 2. "empty type".  An empty type is either an array of empty types or a
>>>>> class type where every member is of empty type.
>>>>> 3. No memory slot nor register should be used to pass or return an object
>>>>> of empty type.
>>>>
>>>> David Majnemer points out that we also need to say something about
>>>> base classes. We could handle that case like this:
>>>>
>>>>  2. "empty type".  An empty type is a type where it and all of its
>>>> subobjects are of class or array type.
>>>>
>>>> Following the C++ rules, this also means that a class that contains
>>>> only unnamed bitfields is empty, because unnamed bitfields are not
>>>> subobjects, but might be worth explicitly stating for the C case. That
>>>> also matches Clang's behavior.
>>>
>>> Like this?
>>>
>>> 1. "class type".  A class type is a structure, union or C++ class.
>>> 2. "empty type".  An empty type is
>>>    a. A type where it and all of its subobjects are of class or array
>>>    type. And
>>>    b. Either an array of empty types or a class type where every member
>>>    is of empty type.
>>
>> You don't need (b). It's implied by (a).
>
> Does (a) cover empty type?

Yes, (a) is a complete definition of "empty type" by itself: the
definition is, essentially, that a complete recursive walk of the type
and all its subobjects never sees anything that would require any
storage (that is, it only sees class types and array types).
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to