Boost logo

Boost :

From: Matthew Wilson (mwilson_at_[hidden])
Date: 2002-06-26 19:21:03


Dave

Quite right on the tone. In hindsight it does seem more than a little curt,
so apologies for that. Write once, repent everywhere ...
(The "Are you serious?" part was actually genuine, as I wondered whether you
were making a joke or not. Clearly the other bits indicate that I decided
you weren't).

As to the body of the matter, I remain concerned that a rapidly expanding
project that (correct me if I'm wrong) intends to avoid being "bloated" can
avoid going down the road of previous such projects. Look at ATL, which
avowed the intent to counterpoint the bloated and decaying MFC - it's
getting pretty fat itself now.

I realise that it's naive to think that every constituent of boost can
remain lightweight (for example, being header-file only): certainly
something such as threads cannot. However, I think it important to be
mindful of the decaying carcasses of MFC and it's ilk on the roadside as we
go speeding by.

Has this issue been explicitly raised/noted/addressed previously? Is there
documentation available online on the interdependencies in the boost
libraries?

Matthew

"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:224101c21d6b$2dc470b0$6601a8c0_at_boostconsulting.com...
> From: "Matthew Wilson" <mwilson_at_[hidden]>
>
>
> > Developers don't want to be bothered with carefully maintaining minimal
> > dependencies. Are you serious? Are they?
> >
> > Stunning.
>
> First of all, let me say as a moderator that the tone of this post is
> entirely inappropriate for Boost. We try to maintain a collegial
atmosphere
> here; see the section of http://www.boost.org/more/discussion_policy.htm
on
> Culture for more information.
>
> Secondly, yes, I'm serious. The kind of minimal dependencies being asked
> about would entail intrusive measures into existing library components
such
> as Boost.Config, to eliminate all definitions not relevant to the actual
> problem being solved by any library that uses Boost.Config. This would be
> an enormous drain of volunteer resources devoted to library maintenance
and
> development, and IMO would effectively undermine Boost.Config's identity
as
> a component. Even a less-extreme example poses problems: if I need to use
a
> template from the type traits library, I don't have the time to exercise
> constant vigilance about what John Maddock might have needed to #include
to
> get it to work right... and I'd prefer that John re-use some component
from
> within boost than to incur the maintenance problems that arise due to
> code/functionality duplication.
>
> -Dave
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk