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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk