|
Boost Testing : |
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