Reply to thread

Message: [QUOTE="James Kanze, post: 3968157"] Note that N2960 is not the standard, but a draft for the next version of the standard. In particular, it differs signficantly from the current standard here (in wording---not in effect). The current standard simply says that a POD must be an aggregate; some of these requirements are part of being an aggregate. But you're formulating it backwards. In order to be a POD, a class must have a trivial default constructor, a trivial copy constructor, a trivial copy assignment operator and a trivial destructor. If any of these is user defined, then it is by definition non-trivial, but there are other ways for them to be non-trivial or absent: a class with a deleted copy constructor, for example (in the draft). If you provide any constructor, the compiler no longer provides the trivial default constructor---either you provide one (which will be non-trivial), or there isn't one. Either way, the class won't be a POD. (Or... I think you can tell the compiler to provide one explicitly, and that might be trivial.) Yes, but either the base class or the class itself must be empty, which sort of makes this provision useless. It seems clear enough to me. Given a hierarchy (which may consist of only a single class), there may be at most one class in that hierarchy which has non-static data members---non-static, because static data members don't affect the layout in any way. I think the original formulation was clearer, and the original rules allowed an informal simplification: a POD is something you could write in C. I'm not sure what we really gain by allowing anything else. I understand the desire of separating "layout compatibility" from POD-ness, since they affect different operations (communication with other languages, memcpy-ability), but in practice, I don't think it makes any difference. [/QUOTE]

Verification