Somewhere in the E.U., le 18/11/2002
Bonjour
"Terje Slettebų" wrote:
>
> >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?
Well, config.hpp only defines things which are necessary to work
around platform deficiencies. For the sake of the discution, let's just
focus on the platform-independant part of some code (platform-dependant
will by its very nature be outside of the standard's bounds).
Not including that header will in no way hinder compilation when
performed on a conformant platform (if such a beast did in fact exist,
and that the rest of the code were conformant), as that header (as far
as I could tell, by looking at it and at the reason for its existance)
defines *NO* service for conformant platforms. So one just includes the
headers one needs for functionality (either in the standard or Boost),
and writes one's (hopefully conformant) code. If all goes well, then
fine. If not, then either we face a deficiency of the platform (no
template templates, for instance) and we take corrective action (we
include the band-aid patch and we complain to the vendor), or we face a
deficiency of the langage (we want need to count with really really big
integers, we need to say that some stuff is made of 8-bits chunks...)
and we're mostly out of luck. In either case we are *aware* of a
problem, and perhaps, with error reporting, we also know just what the
problem is.
> 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.
I like to include only what's needed. Why should I include config.hpp
if I do not need it for the task at hand? "Preventive" inclusion of some
headers may lead to unforeseen and gratuitous problems (header conflicts
do exist...), though in this case the risk is faily limited (to macro
name collision). Again, the use of macros defined in config.hpp is
limited to workarounds for platform deficiencies. If the code you are
writing and the Boost header you are including do not trigger one of
your platform deficiencies, you do *NOT* need that header, and you do
not need to include it. If you do trigger the deficiency, then you do
need to include it (and you might, in the end, still be unable to use
the functionaly you sought). If you are trully minimalist, and know just
what the problem is, you could even go so far as define (and
subsequently undefine) just the needed macro, and not include the
header. As a library writer, one must anticipate (as far as possible)
that the library might be used in a deficient environment, and so use
config.hpp's macros, but I believe that one also needs a way to warn the
user of the presence of deficiencies (so "it did not work out correctly,
apply the band-aid and try again...").
Hiding problems is not a way to solve them.
Well, anyway, since this is deemed confusing, I'll bury the problems
(alive :-) ). To bad "some" compilers will then claim perfect compliance...
A bientot
HH
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
