On Tue, Mar 19, 2013 at 3:59 AM, Marc Glisse
On Mon, 18 Mar 2013, Rene Rivera wrote:
First pass at the Predef header for this at <
. Currently only tested on my OSX laptop. Would appreciate others trying it out. The info is a combination of the indispensable description from
https://raw.github.com/**grafikrobot/boost-predef/** master/include/boost/predef/**endian.hhttps://raw.github.com/grafikrobot/boost-predef/master/include/boost/predef/... predef.sf.net (Bjorn Reese et al), known endian specifications I could find on the architectures I currently detect, and a small amount of general web searching.
If this is supposed to replace detail/endian.hpp, couldn't you define the same macros?
The version in Predef is meant to supplant detail/endian.hpp. When it's working we can see about writing a drop-in replacement if needed.
BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN, BOOST_BYTE_ORDER which can be 4321 or 1234, etc.
If you read the documentation for the Predef library you would see that I'm following a particular naming convention that defines categories (BOOST_category_subcat_subsubcat). I do have some questions regarding the BYTE_ORDER macros.. Are the macros defining the 4321/1234 numbers actually needed? Are there situations where the on/off indicator macros aren't enough? Boost refused to document those because they aren't reliable enough, but
that doesn't mean users didn't come to rely on them.
Since the ones in Predef are documented, and assuming Predef was/is accepted, then it would be a matter of search and replace for user code. But I could also add a "compatibility" mode (with a user define to enable it) that defines the old macros. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo