"John Maddock" <[EMAIL PROTECTED]> writes:
>> >> I don't (yet). Why do we need yet another macro which means "turn off
>> >> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
>> >
>> > I think that the idea is that BOOST_STRICT_CONFIG applies only to
> unknown
>> > compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate
>> > compiler/library macros?) would be applied unconditionally, regardless
> of
>> > whether the compiler has known defects.
>>
>> What's the use of distinguishing those? Surely the person who's doing
>> the testing doesn't care about whether we think we "know" that
>> particular compiler version?
>
> Would you believe that I've rewritten this mail three times with the
> previous two having flaws (discovered just as I'm adding my sig!).
I'm afraid so ;-)
> Hopefully this time this is logically correct, how about this:
>
> If the config system detects a compiler version it knows about, and
> which it knows will likely need compiler specific workarounds, then
> it undef's BOOST_STRICT_CONFIG if it's set (in the compiler config
> files).
This is confusing and a bit alarming.
If the user intentionally sets BOOST_STRICT_CONFIG I don't think our
configuration system should ever undef it. Why would anyone want that
behavior?
Or are you suggesting that users should never set BOOST_STRICT_CONFIG
in the first place, instead leaving that job to our compiler config
files?
> Then we just use BOOST_STRICT_CONFIG as to determine whether to enable
> workarounds or not.
Why can't we do that anyway, without the #undef behavior you suggest
above?
> There are now three use cases if BOOST_STRICT_CONFIG is defined:
>
> 1) We recognise the compiler, and know that it needs workarounds: disable
> BOOST_STRICT_CONFIG.
This is bad [but read to the end because I might change my
mind]. Suppose someone is working with a pre-release of MSVC 8.0. She
knows it has several problems, so adds appropriate workarounds to the
code. How can someone over at Microsoft is test their compiler against
the Boost CVS without workaround, other than by faking the compiler
version number?
Further, suppose someone at Microsoft wants to investigate a problem
in the already-released vc7.1, which seems to have bugs related to the
same problem? Fake-bumping the version number forward for vc7.1 might
be a bad idea because it would pick up workarounds for the 8.0
prerelease.
> 2) We don't recognise the compiler: assume that it is standard
> conforming and disable all workarounds.
Is this a different case from "we recognize the compiler, but not the
compiler version"?
Incidentally, I think we had some kind of agreement a while back
(sparked by Thomas Witt, IIRC) that when a workaround is implemented
for the most recent compiler version, no assumption should be made
that the corresponding bug will be fixed in future versions. I don't
think my macro accounts for that, and I really don't know a good way
to cope with it. I don't think we ought to add any workarounds without
at least some way to record the most-recent version where it's known
to be needed.
> 3) BOOST_NO_COMPILER_CONFIG is set: so irrespective of the compiler version
> all workarounds will be turned off.
O...K...., but why should we not respect BOOST_STRICT_CONFIG in
exactly the same way? It sounds like you want BOOST_STRICT_CONFIG to
have meaning only for compilers that we don't know need any
workarounds. But what difference will it make for those compilers?
> BTW I think your BOOST_WORKAROUND macro belongs in
> boost/config/suffix.hpp if you want to move it there (so we all get
> it),
Until the dust settles, I'd rather leave it in
boost/detail/workaround.hpp. When we get all these other issues
figured out, we can move it.
> and of course it needs docs adding - probably to the helper
> macros table in the config docs.
Remind me when this is all over ;-)
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
