On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith <rich...@metafoo.co.uk> wrote: > 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).
Is there a definition of subobject? -- H.J. _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
