Re: [boost] Review: Config system
- David Abrahams wrote:
> The solution seems obvious to me: we specify a preprocessorAgreed, and thanks to Aleksey for the user's perspective.
> symbol which, when #defined, makes the appropriate assumption for
> developers... shall we say, BOOST_DEVELOPER?
Except that I like BOOST_STRICT better (see other mails on the subject).
- On Friday 31 August 2001 10:15, you wrote:
> Simply put, some workarounds under BOOST_MSVC weren't written expectingIt would be useful in this case if we had macros to emulate a compiler on a
> a conforming compiler from Microsoft. It's usually trivial to fix, but
> it might not work either way with a new version of the compiler.
different compiler. Assuming we have a compiler that does not require any
workarounds (we almost do), it would be great if we could run the regression
tests through that compiler but emulate one of the other compilers to ensure
that we haven't used a bug to our advantage. I do this with Boost.Function,
so even if the old workarounds are used on a new version there shouldn't be a
new failure (unless it's a new bug).
> How about using #error instead? The BOOST user is made very aware theyIt's a pity that #warning is non-standard :(. I don't see any reason to halt
> are entering uncharted territory.
compilation just because the user has a newer compiler. If we make sure that
workaround code is still conforming code, it's reasonable to be pessimistic
about new releases. We can always enable BOOST_STRICT to test out the
capabilities of a new version without forcing the user to do that work for us.