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.