On 2008-05-29 19:51, Beman Dawes wrote:
There are some issues with the base class approach. For it to be a POD, it can't have constructors, base classes, or private members.
I was wrong above ... just the constructs have to be removed. Private members and base classes are OK.
Does that mean the FAQ entry "Are endian types POD's?" in the documentation needs to be changed? Or do you just mean what's said in the next FAQ entry, that "this problem has never been observed in a real compiler"? If we do implement the suggestion of a switch to turn off the definition of constructors, there will of course need to be some adjustments to the documentation. I'm still thinking about what those changes might usefully be. BTW, if you are making changes to the documentation, I have a very minor suggestion. In "What are the implications of C++03 endian types not being POD's?", it would make for easier reading if you made it clearer that there are two points being made; eg "Also, compilers aren't required to align or lay out storage in portable ways for non-POD types, although in practice this problem has never been observed in a real compiler." --Neil