Re: [boost] Re: Boost to the rescue

From: Dave Harris (brangdon_at_[hidden])
Date: 2005-04-17 13:09:23

In-Reply-To: <6.2.0.14.2.20050417091210.0840a328_at_[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.

Basically I am supporting the idea of splitting boost into a collection of 
small, independent packages. 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 didn't want to include anything I couldn't see an immediate use for. 
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.

> > 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.

> 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.

-- Dave Harris, Nottingham, UK.