Boost logo

Boost :

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-06-14 14:18:57

On 6/9/05, Caleb Epstein <caleb.epstein_at_[hidden]> wrote:
> On 6/8/05, Caleb Epstein <caleb.epstein_at_[hidden]> wrote:
> > On 6/8/05, Caleb Epstein <caleb.epstein_at_[hidden]> 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

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