On Fri, 12 Mar 2004 14:20:08 -0500, David Abrahams <dave@boost-consulting.com> wrote:

Gennaro Prota <gennaro_prota@yahoo.com> writes:

...

Intel C++ for Windows never stops surprising me with its Microsoft bugtibility conundrums. When you use /Qms0 (version 8.0) it defines _MSC_VER to be 1200, as if it emulated VC++6!

CRIMINY!!!!

:)

Did you report this as a bug to Intel?!?

I've now verified that it *always* defines _MSC_VER to be 1200, except when you use /Qvc7.1. Aarghh. FWIW, the compiler user's guide just says that on IA-32 _MSC_VER is 1200. No, I've no idea of how to report bugs to Intel. However I have an unpatched evaluation version (8.0.040). Can you verify if 8.0.042 has the same problem? -- Genny.

// No, I've no idea of how to report bugs to Intel. However I have an // unpatched evaluation version (8.0.040). Can you verify if 8.0.042 has // the same problem? I've submitted a defect report. Stefan

// -----Original Message----- // From: boost-bounces@lists.boost.org // [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota // // Thanks, Stefan. I doubt they will fix the situation though. I wish I // could use the --microsoft_version switch of EDG, but it doesn't work // either :) I think they will do and, as I know Intel, if they do they do it quickly. I don't know how it influences the macro configuration, but what you are looking for is /Qoption,cpp,--microsoft_version=1310 Stefan

Thanks, Stefan. I doubt they will fix the situation though. I wish I could use the --microsoft_version switch of EDG, but it doesn't work either :) And, anyway, that wouldn't be a solution for boost (at least not for header-only libraries). Let's see what John says about the config system.

I'm keeping quite and hoping that someone else will solve the issue :-) If my understanding is correct, then: * we need to detect whether the std lib was the one that shipped with vc6, 7 or 7.1 but: * we can't use _MSC_VER because it gets set to arbitrary values. * we can't use the Intel compiler version because Intel 8 can sit on top of vc6 and 7 as well as 7.1 * so we need a method that relies on the std lib alone, except that there isn't one.. Is that right? John.

On Mon, 15 Mar 2004 13:28:57 -0000, "John Maddock" <john@johnmaddock.co.uk> wrote:

I'm keeping quite and hoping that someone else will solve the issue :-)

:) [PS: out of curiosity, is 'quite' a typo for 'quiet' or a sort of play on words?]

If my understanding is correct,

Hmm... when you say so I begin worrying :)

then:

* we need to detect whether the std lib was the one that shipped with vc6, 7 or 7.1 but:

Well, we can assume that the version shipped with VC6 is used with VC6 only, can't we?. It's newer lib versions that can be used with everything (maybe - please confirm this :)).

* we can't use _MSC_VER because it gets set to arbitrary values.

Yes. But I have a question: can we assume that the compiler is always detected *before* the library? Currently that's what the config system does. If it isn't a problem to cast this fact in stone, then the library config could just use BOOST_MSVC. I would go further: I think once the compiler config has identified a compiler it should make available those information to the user (the library writer). That is, there should be e.g. a BOOST_GCC defined for g++, but not for Intel in gcc compatibility mode. That's something I need very often and needs just a simple #define for each compiler config file. Without that, say, for instance, I need to workaround a gcc bug (as it happened to me yesterday); then I have to do something like this: #if defined __GNUC__ && !defined BOOST_INTEL_CXX_VERSION \ && /* not compiler xyz1 emulating g++*/ \ && /* not compiler xyz2 .... \ ... workaround code... #endif when I could just do #if defined BOOST_GCC ... workaround code... #endif That also makes library code immune if new compilers that emulate g++ are introduced: you only change the config files (which need to be changed anyway) and the library code works as a consequence.

[snip]

-- Genny

On Tue, 16 Mar 2004 16:15:14 -0000, "John Maddock" <john@johnmaddock.co.uk> wrote:

Yes, it's detected first, and yes we can use BOOST_MSVC to detect "real" msvc, but that doesn't help with the Intel config:

As far as I can tell from Intels docs, all it's predefined macros are set to the same values irrespective of whether it's been installed on top of VC6, VC7, or VC7.1.

Yes, but I don't think it emulates the compiler it is installed on top of. Does it? I suppose Intel 8.0, for instance, is always VC7.1-like in the language support, even if installed on top of VC6. What "remains" of the underlying VC installation, besides the linker etc., is the (non-)standard library. But that is detectable with certainty.

...

[...] Yep, good idea, it just doesn't solve this issue :-(

Is this ironical? I really think it is a good idea! :) -- Genny

On Wed, 17 Mar 2004 12:50:04 -0000, "John Maddock" <john@johnmaddock.co.uk> wrote:

...

What "remains" of the underlying VC installation, besides the linker etc., is the (non-)standard library. But that is detectable with certainty.

Is it, how?

Just like you do now. Am I missing something? (With "that" I meant "the library"). In stdlib/dinkumware.hpp there's, for instance: #if defined(_CPPLIB_VER) && (_CPPLIB_VER >= 306) // full dinkumware 3.06 and above // the library is conforming; but some features // can't be used if the compiler is (real) VC6 // # if THIS_IS_REAL_VC6 /* defined BOOST_MSVC &&... */ # define BOOST_NO_STD_USE_FACET # define BOOST_HAS_TWO_ARG_USE_FACET ... # endif #else // <old version: has defects, regardless of the compiler> # define BOOST_MSVC_STD_ITERATOR 1 # define BOOST_NO_STD_ITERATOR # define BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS ... #endif Isn't that enough? -- Genny.

On Thu, 18 Mar 2004 11:26:37 -0000, "John Maddock" <john@johnmaddock.co.uk> wrote:

Sounds like it's close enough, it might fail for people with VC6 + Intel and an updated Dinkum library,

Why?

but that'll just have to be too bad, changes in mainline cvs now.

Thanks. Now, pardon me if I have other questions (all concerning the part that follows the #if/#endif above): - shouldn't the test for BOOST_STD_EXTENSION_NAMESPACE be based on the *library* version, rather than _MSC_VER? - shouldn't BOOST_NO_STD_ITERATOR_TRAITS test for "real" VC6? <debatable> At the cost of duplicating the definition, maybe it would be clearer to do: #if defined(_CPPLIB_VER) && (_CPPLIB_VER >= 306) // full Dinkum # if REAL_VC6 ... # define BOOST_NO_STD_ITERATOR_TRAITS // <--- # endif #else // old Dinkum ... # define BOOST_NO_STD_ITERATOR_TRAITS // <--- #endif </debatable> - The test for BOOST_NO_STD_LOCALE is really restrictive. Fortunately it only refers to the Dinkum lib shipping with VC7. However if many of our users use Intel C++ with that library then it might be worth to soften it, because it really prevents a lot of code to work. (Well, this is not really a question :)) PS: I'm not one who claims that others do work that he could do. It's just that these issues are a bit delicate and I wanted to see with you if there's any problem I'm missing. After that, I could commit the changes for you, if you like. This also holds for the compiler identification macros, after we agree on the names, of course. I propose: BOOST_COMEAU_CPP or BOOST_COMEAU_COMPILER BOOST_GNU_CPP or BOOST_GNU_COMPILER BOOST_INTEL_CPP or BOOST_INTEL_COMPILER BOOST_MSVC (well, this is a bit inconsistent :( Ideas?) -- Genny.

...

Sounds like it's close enough, it might fail for people with VC6 + Intel and an updated Dinkum library,

Why?

Because although the library version number will be updated, it will still be a broken library (because Dinkumware ship libraries that are preconfigured to a particular compiler).

...

but that'll just have to be too bad, changes in mainline cvs now.

Thanks. Now, pardon me if I have other questions (all concerning the part that follows the #if/#endif above):

- shouldn't the test for BOOST_STD_EXTENSION_NAMESPACE be based on the *library* version, rather than _MSC_VER?

- shouldn't BOOST_NO_STD_ITERATOR_TRAITS test for "real" VC6?

Same problem, it doesn't matter what the library version number is, because the Dinkum library is preconfigured for a particular compiler, it doesn't become un-broken just because we're using Intel, if was originally configured for VC6/7, then it will always be broken, period.

<debatable> At the cost of duplicating the definition, maybe it would be clearer to do:

#if defined(_CPPLIB_VER) && (_CPPLIB_VER >= 306) // full Dinkum

# if REAL_VC6 ... # define BOOST_NO_STD_ITERATOR_TRAITS // <--- # endif

#else // old Dinkum ... # define BOOST_NO_STD_ITERATOR_TRAITS // <--- #endif </debatable>

- The test for BOOST_NO_STD_LOCALE is really restrictive. Fortunately it only refers to the Dinkum lib shipping with VC7. However if many of our users use Intel C++ with that library then it might be worth to soften it, because it really prevents a lot of code to work. (Well, this is not really a question :))

Sure, but Intel was choking on anything that included <locale> (or even did any vaguely non-trivial stream io) - if you can verify that this has been fixed with Intel 8 (I'm sure it probably has), then lets add an Intel version check and re-enable this for Intel 8.

PS: I'm not one who claims that others do work that he could do. It's just that these issues are a bit delicate and I wanted to see with you if there's any problem I'm missing. After that, I could commit the changes for you, if you like. This also holds for the compiler identification macros, after we agree on the names, of course. I propose:

BOOST_COMEAU_CPP or BOOST_COMEAU_COMPILER BOOST_GNU_CPP or BOOST_GNU_COMPILER BOOST_INTEL_CPP or BOOST_INTEL_COMPILER

BOOST_MSVC (well, this is a bit inconsistent :( Ideas?)

Personally I prefer the BOOST_GNU_COMPILER versions, but we already have BOOST_INTEL_CXX_VERSION, so maybe BOOST_GCC_CXX_VERSION etc? Thanks, John.

...

Sure, but Intel was choking on anything that included <locale> (or even did any vaguely non-trivial stream io) - if you can verify that this has been fixed with Intel 8 (I'm sure it probably has), then lets add an Intel version check and re-enable this for Intel 8.

Sorry, I can't, because I have no access to the VC7's Dinkum.

OK I'll look into it when I get a chance.

My goal was to choose short names, as otherwise preprocessing lines easily become enormous (if nothing else, it's a boost guideline to not exceed 80 characters). Note that even things like:

#if BOOST_MSVC >= 1200

are usually rewritten as

#if defined(BOOST_MSVC) && BOOST_MSVC >= 1200

just because gcc warns about the first form when using -Wundef. And something like

#if defined(BOOST_GCC_CXX_VERSION) && BOOST_GCC_CXX_VERSION >= 295

is already 66 characters.

I see where you're coming from, so how about just BOOST_GCC/BOOST_BORLAND/BOOST_INTEL etc, probably added on an "as needed" basis.

<thinking out loud>

If it wasn't for the gcc warning above, there's another idea that could be explored, which would allow, for instance, writing:

std::cout << "Compiler version is: " << BOOST_COMPILER_VERSION << '\n';

That is: you choose a numeric ID for each compiler (in practice

#define BOOST_BORLAND 1 #define BOOST_COMEAU 2 #define BOOST_COMPAQ 3

etc..). That would be done once, in select_compiler_config. Then in each compiler specific header you define BOOST_COMPILER to the appropriate id. For instance, in gcc.hpp

#define BOOST_COMPILER BOOST_GNU #define BOOST_COMPILER_VERSION ...

Usage would be:

#if (BOOST_COMPILER == BOOST_GNU) && (BOOST_COMPILER_VERSION == ...)

but, as I said, we would have probably complaints from gcc users. The user could also derive something like:

enum compilers { borland = BOOST_BORLAND, comeau = ... };

</thinking out loud>

Looks a little too complicated to me...

PS: For gcc I propose the following definition:

#if defined(__GNUC_PATCHLEVEL__) # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__ ) #else # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100) #endif

Yes, that looks about right. John.

...

...

- The test for BOOST_NO_STD_LOCALE is really restrictive. Fortunately it only refers to the Dinkum lib shipping with VC7. [...]

Sure, but Intel was choking on anything that included <locale> (or even did any vaguely non-trivial stream io) - if you can verify that this has been fixed with Intel 8 (I'm sure it probably has), then lets add an Intel version check and re-enable this for Intel 8.

Sorry, I can't, because I have no access to the VC7's Dinkum.

OK, checked and working with Intel 8. However I have discovered another good reason to use and rely upon -Qvc7.1 and -Qvc7 : without these not only does the Intel compiler set _MSC_VER to 1200, but it also disables things like ADL :-/ John.

"John Maddock" <john@johnmaddock.co.uk> wrote: // // As far as I can tell from Intels docs, all it's predefined macros are set to // the same values irrespective of whether it's been installed on top of VC6, // VC7, or VC7.1. // I wonder what Intel could do: the compiler can be integrated in more than one VS version on the same machine, that's why you can't speak about an "installation on" a particular version. So IMO, the only possibility for setting the _MSC_VER macro is interpreting the /QvcXX switches on the command line. I think that just the default value is wrong: it should be 1310 instead of 1200. What do you think? Stefan