Boost logo

Boost :

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 <
>> master/include/boost/predef/**endian.h<>
>> >.
>> Currently only tested on my OSX laptop. Would appreciate others trying it
>> out. The info is a combination of the indispensable description from
>> (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.

> 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. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at, gregod at, cpdaniel at, john at