Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-02-29 18:17:09


On 2/28/04 5:26 PM, "Eric Niebler" <eric_at_[hidden]> wrote:

> This concerns all boost developers. Please read!
>
> I have just added documentation for how to deal with min/max in boost
> code. I have added it to the "Boost Library Requirements and Guidelines"
> document (boost/more/lib_guide.htm). That seemed the appropriate place,
> but it might be hard to find. If anyone thinks this belongs in a more
> prominent place, please suggest one.
>
> For reference, here is the text I have added:
[TRUNCATE]

In another post, I mentioned an alternate fix to this problem. Here, I'll
talk about your specific fix.

You seem to be assuming:

    The Windows header macros are Boost-hostile

But from recent posts about the problem, I think:

    The Windows header macros are Boost-hostile _and_ STL-hostile

We can "fix" all the Boost code, but we can't change the STL files. Since
Boost (pretty much) requires STL, the user is screwed anyway. This means
that there was no point in changing our code!

I've heard that the Windows headers themselves don't use/need the macros,
they would only exist in user code. If the macros are disabled, then the
user can change to the STL versions.

If we force the user to disable the macros, then the user can do an one-time
change to his/her code to be Boost/STL compliant _and_ Windows compliant
(since Windows doesn't break if the macros are disabled). The current "fix"
forces all Boost developers to rewrite code forevermore because of some
obsolete code, even if the developer doesn't use Windows! I consider the
current state to be a _horrible_ trade-off.

If you're burnt-out from adding the "fix", I'll volunteer to rip it all out.
Just give me a list of all the files you changed. (If it can be undone from
CVS, without screwing up any changes that happened afterwards, then you can
do that instead.)

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk