Boost logo

Boost :

From: Neil Mayhew (neil_mayhew_at_[hidden])
Date: 2008-05-29 23:53:17

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at