From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-11-16 08:09:13
>From: "John Maddock" <jm_at_[hidden]>
> > Well, it was intentional, if not very smart.
> > The idea was that the config files essentially allowed workarounds for
> > platform deficiencies, so if your platform was conformant, you did not
> > need them. Including the config from the headers hides from the user his
> > platform's deficiencies, whereas he should be (painfully) aware of them
> > so as to complain to his vendor. Having to include the config files in
> > user code was supposed to raise awareness of the problem. Of course, for
> > the test files, they must be present.
> > If this is found to be confusing or unwieldly, I can change.
> Yes please, this approach is a sure fire way to confusion IMO, and is not
> the way that the rest of boost is doing things...
I agree. The library user should be insulated from platform differences
(such as deficiencies), or the code won't be portable. That's the point of
Boost.Config, to encapsulate platform differences, so that portable code may
Besides, I find it hard to understand how an optional inclusion of
config.hpp could work at all. If you use _any_ config macro, you need
config.hpp, to have it set correctly. Could you (Hubert) explain how such an
optional inclusion could work?
The point is that if you use config.hpp macros in the library, you need to
include it. If you don't, there's no point in including it. This is not up
to the user of the library, at all, regardless of what platform they are
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk