[boost] Re: config.h[pp]

From: Paul Baxter (paje_at_[hidden])
Date: 1999-07-14 04:21:14

> BTW, do you have to explicitly include
> that header somewhere, or is it implicitly included by the other headers?
I
> can find no docs that mention it, and the code is Byzantine, to say the
> least).

Try looking at the STLPort 'version' of SGI's STL

There is a little more documentation of such issues at
www.stlport.org

This might help unravel some of SGI's macros, what to include etc.

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

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'

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.)

3) Insist boost only accepts non-macro'd solutions.

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.

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

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?)

Paul Baxter

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

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