After reading up on past discussions about what people want from a set of standard macros for compiler identification, I put together a wiki page with past information on the subject and my ideas as to what the consensus is. And basic proposal based on the ideas:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig
Discussion, contributions, funny anecdotes are welcome :-)
(1) BOOST_VERSION_NUMBER macro
Overall, I like it, as someone else suggested you may need to reserve a few more digits here and there, as long as we don't end up overflowing a 32-bit int of course.
For each compiler 'boost/config/select_compiler_config.hpp' would define a macro as '0' by default
That won't work: users can short circuit that header so that it doesn't get included as documented here: http://www.boost.org/libs/config/config.htm#advanced_config We could define any macro that's not already been defined in suffix.hpp though. I like your choice of names for the macros BTW.
For some compiler toolsets it's possible that multiple macros are defined. For instance this would be the case for EDG based compilers >where one would want to know both the EDG version and the specific vnedor compiler version. ANother being compilers that are >frontends to other system compilers, like the Intel compiler. For those reasons it would be better to create new headers which contain the >above definitions per compiler. This would allow them to be defined once and included where appropriate. Hence we would need to add >the following headers:
I don't understand the logic there, why the extra headers? Taking Intel on Linux as an example, it includes common_edg.hpp which would define BOOST_CXX_EDG, then intel.hpp would define BOOST_CXX_INTEL, I'm not sure whether BOOST_CXX_GCC should be defined as well, but intel.hpp could define it if required. Likewise with the platform headers: I don't see the need for the extra headers, the only macro that can be defined in combination with the other appears to be BOOST_PLATFORM_POSIX and presumably that would be defined in the existing posix_features.hpp? Looks like you need to cull some more std lib information to get the version numbers :-) John.