[boost] Re: config.h[pp]

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
macros,
>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
version
>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
until
>compiler X and its library is deemed compliant (say gcc 3, std c++
lib3)
>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
together
>with the macro'd version (if required)
>If an author creates a macro'd version it would be relatively easy
for
>him/her to edit for a 'clean' version. The clean version is the one
that
>boost supports, but the macro'd version is available for download as
a
>practicality.
>None of boost's libraries are very large, so it should not be too
great a
>burden on authors.
>They can just submit a non-macro'd version. (They can't just submit
a
>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.

Too Draconian.

>4) Accept macros as a necessary evil for now but when peer reviewed
look for
>macros that can be avoided without loss of
generality/understandability of
>the code.

Yes, that seems practical without catering to deliberate subsets.

>Note that other than option 3, we would need to define a consistent
scheme
>for config.hpp.

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
compiler
>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
concentrate
>on things that the standard defines as possible, or is it likely
we're going
>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.

--Beman

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications