On 6/9/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 6/8/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 6/8/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
I've commited fixes for these to CVS just now, but I'm *not* sure how to best address the BOOST_BIG_ENDIAN issue. Any suggestions there?
I think perhaps a new header file, <boost/endian.hpp> makes the most sense here.
I don't think the definition of BOOST_BIG_ENDIAN / BOOST_LITTLE_ENDIAN belong in <boost/detail/limits.hpp> This header is not included unless BOOST_NO_LIMITS is defined, which I assume is only for non-standards-conforming implementations.
Does anyone have an opinion on this? Should there be a <boost/endian.hpp> that defines e.g. BOOST_{BIG,LITTLE,PDP?}_ENDIAN? There are two failing tests in Boost.Serialization that need to know if we are on a BOOST_BIG_ENDIAN platform.
Lets try this one more time, but I'll rephrase my question. Does anyone object to me adding a new header <boost/endian.hpp> for this purpose? Or perhaps <boost/detail/endian.hpp> as it would be undocumented. This is all that is required to make the gcc-3_4_3-sunos target 100% pass on all tests. It will also fix any other big-endian platform where the Boost.Serialization test_demo_portable_archive{,_dll} is failing (Darwin I think). I don't know if this qualifies as a "new feature" or not, but I think it would be nice to have, particularly if any networking code gets introduced any time soon. -- Caleb Epstein caleb dot epstein at gmail dot com