Re: [boost] [PREDEF] Review for the Boost.Predef library by Rene Riviera

Subject: Re: [boost] [PREDEF] Review for the Boost.Predef library by Rene Riviera
From: Iain Denniston (iain.denniston_at_[hidden])
Date: 2012-02-27 12:02:00

FWIW some musings based on a quick look at the library* and other 
peoples comments.

- I understand the rational that led to the library structure, but it 
does seem a little too much, especially when all headers are included 
all the time. It occurs that it might be better to have a single NULL 
definition header which defines all definitions of a given type (e.g. 
compiler) as 0 or equivalent then each platform includes a single header 
of each type which would redefine any supported macros. This would also 
mean a single location of all macros would exist in code which would be 
handy for quick checks (though I realise this is not a compelling 
argument!).

- The above assume a NULL defined style macro rather than an undefined 
macro style – as has been mentioned I think perhaps undefined macros are 
the better choice for these very low level definitions. I’d suggest it’s 
likely that if you have to use these for areas of the code then the code 
being blocked off is likely not legal in most other cases (and so the 
alternative C++ compiler “if” usage would not be possible anyway and so 
removes the only reason I can see to have things as they are).

- Why does the library use division and modulo as a means of extracting 
values from version numbers? To me this is inherently confusing, easy to 
misread, and error prone. Using shifts and hex masks would make much 
more sense (at least in some cases), but I appreciate I may be in the 
minority here.

- The version macros seem to be missing some obvious, um, versions, if 
they are intended to be used by users and to extend the library it would 
be good to see all “obvious” versions supported out of the box (e.g. 
“NN”, “NN_NN_NN_NN” and I note that Windows version numbers would 
require a “NNNN_NN_NN”)

- C++ language version is all well and good, but it doesn’t help much 
when trying to work out if a compiler supports a specific feature. It 
may be beyond the (initial?) scope of the library, but it’d be nice to 
see some definitions for language features (I realise some are available 
elsewhere in boost, but they would seem fit for predef IMO). (So things 
like varadic templates or partial template specialisation, etc.)

- I’d add my vote to shorter names (e.g. ARCH)

- Finally I very much prefer “CPP” to “CXX” - .cpp seems all but 
standard as file extension to have macros with CXX rather than CPP seems 
odd (but I understand why it might be better and this is purely a 
personal preference).

Just my thoughts :oP

Iain

*Although I've looked at the library a bit I have not used it - I'm very 
interested in it though.