On Tue, 14 Jun 2005 15:18:57 -0400 Caleb Epstein <caleb.epstein@gmail.com> wrote:
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.
I actually brought this subject up a while ago (see http://lists.boost.org/MailArchives/boost/msg68195.php). The thing that really did me in for a compile time check is the new architectures that allow you to change endian-ess on the fly at runtime (http://lists.boost.org/MailArchives/boost/msg09120.php). Thus, I fell back to runtime detection in the stuff I was doing.