John Maddock wrote:

...

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.

I already changed the patch number from 3 to 5 digits. So it's now at 3 digits for major, 3 for minor, and 5 for patch. Which Hmm, which blows up the 32 bit barrier :-( That barrier realistically only allows for 3/3/3 at up to 1,000,000,000 (closest decimal round number lower than 2^32). So if we want more than 9 digits we'll have to figure out some other way. Ideas welcome ;-)

...

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.

OK, I'll adjust accordingly then. Is it OK to then define all the compiler, platform, and stdlib macros in suffix.hpp?

I like your choice of names for the macros BTW.

Thanks :-)

...

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.

Yes, EDG is a special case since it already has a common header where the version macro could be defined. But it seems more forward thinking to generalize the structure so that we don't have to go adding more special cases in the future. And the one thing we *really* want to avoid is duplication of the code to define the version macros, by for example defining BOOST_CXX_GCC in both intel.hpp and gcc.hpp, as that will surely lead to errors.

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?

Again I didn't want to assume it's going to be that way in the future. But sure if we think that POSIX is the only platform that will ever be defined in addition to all other platforms we can certainly put the version definitions into the specific platform headers.

Looks like you need to cull some more std lib information to get the version numbers :-)

Yep, and I'll need some help as I don't have access to most platforms and the current headers don't have enough for me to figure out the version info, if any. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

John Maddock wrote:

...

...

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.

Yes, EDG is a special case since it already has a common header where the version macro could be defined. But it seems more forward thinking to generalize the structure so that we don't have to go adding more special cases in the future. And the one thing we *really* want to avoid is duplication of the code to define the version macros, by for example defining BOOST_CXX_GCC in both intel.hpp and gcc.hpp, as that will surely lead to errors.

Understood.

However do we really want to define macros for more than one compiler at once? The whole reason for introducing BOOST_MSVC was because other compilers were pretending to be msvc.

I'll take your word for it :-) I didn't find a mention of that in the list searches I did. But it seems logical that is the reason we would have that macro. And it does make sense in the Intel case that we would want to treat it as just one compiler. I suspect that for compilers like Intel, which are front ends to others, we will want some other define to say what the target compiler is. But that can be up to the individual compilers. And since we would have the BOOST_VERSION_NUMBER macro those defines would at least be consistent :-) OK, so I'll remove the various *_version.hpp files from the proposal.

Again, I don't think we should ever have more than one platform macro set, otherwise any code that's testing for that won't know what to do.

Agreed. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org