Boost logo

Boost :

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-04-17 21:07:27

At Sunday 2005-04-17 11:09, you wrote:
>In-Reply-To: <[hidden]>
>vawjr_at_[hidden] (Victor A. Wagner Jr.) wrote (abridged):
> > > The shear size of boost bothers me in that I don't want to burden
> > > my source code control system unnecessarily.
> >
> > 21 meg isn't that much (for the headers)
>Actually it's quite a lot. This is a "new tool" issue - once any new tool
>is incorporated into the code, we have to keep it around for ever, even if
>it proves useless and we stop using it 6 months later. It's a barrier to
>entry, and it would be a lower barrier if boost took 1 meg or 10k.

do you keep all versions of your compiler around forever?

>Basically I am supporting the idea of splitting boost into a collection of
>small, independent packages.

I don't see how that will help, but if you do, feel free to do so, I'll
regression test anything.

> I don't know how big the subset I selected
>was, but it was probably nearer 10k. From memory it was operator.hpp,
>smart_ptr.hpp and static_assert.hpp, plus whatever they depend on (which I
>discovered by repeatedly attempting to compile).

I have no idea how much (size or number of files) of the boost library I
use in any (or even all) of my projects that use boost. It's completely
irrelevant to me and I'm not sure I see the relevance to anyone.

>I didn't want to include anything I couldn't see an immediate use for.

a true forward looking point of view.

>Instead I encouraged my colleagues to view the website and add anything
>they wanted from it. Nobody has yet done so, which I suppose weakens the
>claim that a small subset will lead to a bigger one.
> > > The dependency issue bothers me too.
> >
> > You'd seriously rather that people copy/paste code to reduce
> > dependencies?
>There's a trade-off. It depends on the size and complexity of the library
>code. For example, I once experimented with using operators.hpp to
>generate != from ==. The benefit seemed borderline. There is a hump
>involved in using 3rd party code, and for a one-line routine:
> inline bool operator!=( const MyType &a, const MyType &b ) {
> return !(a == b);
> }
>it hardly seems worth it. Operators.hpp has over 900 lines of code, full
>of #ifdef's for various compilers, templates and inheritance. To
>understand it you need to know about subtle language issues: for example
>how the inline "friend" generate non-member functions, or the nuances of
>the empty base class optimisation. The documentation is long and
>complicated. None of this can be understood at a glance, where-as the
>hand-written version above can.

actually you don't need to "understand it" to use it, anymore than you need
to understand the workings of the transmission in the auto you drive.

> > > I've had code break because a boost header somewhere redefined min
> > > and max.
> >
> > where? when?
>A few weeks ago. Probably using boost 1.31 - I'm not at work to check. I
>don't recall which header I #included. Probably shared_ptr.hpp.

I find it difficult to believe that min and or max got "redefined" such
that they became unusable (I'm pretty sure it would have shown up in the
regression testing. I recall no such incident).

> > the real problem is that MicroSloth [...] #define min and max as
> > a result of using windows.h !!!!
>I know. The point remains. Experienced programmers know that using any 3rd
>partly library can introduce problems. Boost is no exception.

Experienced programmers know that using any code can introduce
problems. This belief that "we're better than everyone else" is folly.

>-- Dave Harris, Nottingham, UK.
>Unsubscribe & other changes:

Victor A. Wagner Jr.
The five most dangerous words in the English language:
               "There oughta be a law"

Boost list run by bdawes at, gregod at, cpdaniel at, john at