>From: "John Maddock" <[EMAIL PROTECTED]> > > 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 be written. 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 using. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost