Re: [boost] Re: Boost to the rescue

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

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: http://lists.boost.org/mailman/listinfo.cgi/boost

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