Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2004-03-16 11:15:14

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

Sorry, typo.

> >
> >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.

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.

> 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.

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at