Boost logo

Boost :

Subject: Re: [boost] Library dependencies and intrer-library code reuse
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-03-26 09:30:49


On Fri, Mar 26, 2010 at 3:11 AM, David Abrahams <dave_at_[hidden]> wrote:

> At Thu, 25 Mar 2010 22:58:45 -0500,
> Zachary Turner wrote:
> >
> > On Thu, Mar 25, 2010 at 10:43 PM, Steven Watanabe <watanabesj_at_[hidden]
> >wrote:
> >
> > > AMDG
> > >
> > >
> > > Zachary Turner wrote:
> > >
> > >> So there we go. Does this work, and if not why not? Even if we
> agree
> > >> it's
> > >> a huge undertaking, is it worth it? And if not, why not?
> > >>
> > >>
> > >
> > > Even if it were a good idea, it isn't going to happen.
> > > Nothing that requires that much effort is ever going
> > > to happen around here. If we did have that kind of
> > > manpower, I think there are many higher priorities.
> > >
> > >
> > Surely we can't adopt that stance forever can we? It's not difficult to
> > imagine a scenario down the line where Boost has hundreds of independent
> > libraries. This won't scale. It *cant* scale. But at the same time, it
> > really doesn't make sense for everyone to continue reinventing wheels in
> > every single new library that gets added to boost. It defeats the whole
> > purpose of having a generic library in the first place, and makes the
> exact
> > problem that everyone complains about (slow compile times) even
> > worse!
>
> Untangling (and minimizing) intra-library dependencies is certainly
> doable—the untangling part has already been done
> (http://gitorious.org/boost)—but you proposed something more radical…
> and probably impossible when you consider the pimpl/header-only
> requirement. A pimpl-based type traits library?
>
>
Ok, sure. In some cases it's not possible. I guess I didn't explicitly say
that because I thought it was kind of obvious but you're right, I should
have clarified, or at least not emphasized *every* library. But the point
was that if it's possible, it should be done. I think that it's possible in
large part for almost every library which is not strictly a metaprogramming
library, or which generates some runtime code. Most libraries use some
element of metaprogramming, but oftentimes they are internal details and the
metaprogramming-related headers can be included only from CPP files.

Like you said, minimizing inter-library dependencies isn't that impractical.
 My point was that I don't think minimizing inter-library dependencies is
necessarily a worthy goal. We should *encourage* libraries to use other
libraries, while mitigating the negative effects of these dependencies from
the user's point of view.

Zach


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