From: Beman Dawes (beman_at_[hidden])
Date: 1999-07-14 12:41:23
At 10:21 AM 7/14/99 +0100, Paul Baxter wrote:
>On the main 'macros, point, I'm caught between the purist view - no
>standard C++ is what we want,
>and the practical view - I use egcs and MS Visual C++, gulp.
>The ink is only just dry on the standard, we all HOPE that the next
>of every compiler is
>standards conforming, but this will take a little while.
>I suggest the following possible solutions:
>1) Macro control is highly discouraged and will only be allowed
>compiler X and its library is deemed compliant (say gcc 3, std c++
>Estimated ~ 1yr. i.e. set a freely available compiler as the 'guide'
Well, not one single compiler, but rather use several of the
widely-used compilers as the guide. And rethink that in a year or so
depending on current realities.
>2) Suggest that submissions include a non-macro'd standard version
>with the macro'd version (if required)
>If an author creates a macro'd version it would be relatively easy
>him/her to edit for a 'clean' version. The clean version is the one
>boost supports, but the macro'd version is available for download as
>None of boost's libraries are very large, so it should not be too
>burden on authors.
>They can just submit a non-macro'd version. (They can't just submit
>macro'd version however.)
The maintenance problems for this approach are just too great. None
of the Boost libraries are large now, but that isn't a permanent
condition. I know I am working on a larger submission, and view the
current libraries as just preliminaries. I expect other authors feel
the same way.
>3) Insist boost only accepts non-macro'd solutions.
>4) Accept macros as a necessary evil for now but when peer reviewed
>macros that can be avoided without loss of
Yes, that seems practical without catering to deliberate subsets.
>Note that other than option 3, we would need to define a consistent
For now, I will act as gatekeeper, and will ask for opinions when
authors want new #defines added to boost/config.h. That makes the
process heavyweight enough to discourage undesirable additions.
>This does all assume that we would only use the macros to cope with
>deficiencies. What would we do with say a basic threads library?
>This would have a different underlying threads system on different
>architectures. Will boost always steer clear of such things and
>on things that the standard defines as possible, or is it likely
>to need macros for this anyway. (std_cfg.hpp and os_cfg.hpp anyone?)
This sort of totally platform dependent implementations is better
handled by separate implementations files for each platform, free of
most macros, and conforming to the documented interface.
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk