Subject: Re: [boost] License of endian and limits in Boost detail
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2013-03-19 10:00:59
On Tue, Mar 19, 2013 at 3:59 AM, Marc Glisse <marc.glisse_at_[hidden]> wrote:
> 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
>> predef.sf.net (Bjorn Reese et al), known endian specifications I could
>> on the architectures I currently detect, and a small amount of general web
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk