Re: [integer] Promotion of endian library code from vault

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost