Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-25 20:28:58

> It is soo difficult, that I am very reluctant to use others template
> based libraries.  I approach them with fear.

> That being said, boost::mpl and boost::spririt are wonderful
> accomplishments and I use them regularly.

>> >> So fear depends on author?

No, I just no khow many times I have re-written my own designs.
Its just so god-damn hard to get right.

Those that do, my hats off to them.

On Thu, Mar 25, 2010 at 4:37 PM, Markus Werle
<numerical.simulation_at_[hidden]> wrote:
> Tom Brinkman wrote:
>
>
>> 3) Dependencies.
>
>>  its practically impossible to isolate the ones
>> you want from
>> from the ones you don't.
>>
>> What does this mean?
>>
>> Well, it requires the leads of a given project to create a policy about
>> which boost libraries are approved and which ones aren't.
>
> I agree we have a dependency jungle problem within boost.
>
>
>> Because of the difficulty of doing this, after a while, its can become
>> eaiser to just say "screw it". We won't use boost at all.
>
> OTOH if the great benefit of using some boost library is not obvious to the
> project lead and the lead "screws" it just because of defects within the SD
> process (no review?) and team communication isssues then the lead should
> change and not boost.
>
>> This issue may seem trivial, but it is the cause endless hourse of grief.
>>
>> It seems that once you add boost to your project, some developers feel
>> that you should be able to use any part of boost.
>
> AFAICS there are not too many C++ libraries around that can compete those in
> boost. Most of the times the boost version is superior.
> So "if in doubt, take it from boost" is probably a GoodThing.
> I do not see a problem here.
>
>> For obvious reasons, project leads prefer to have control over which
>> libraries are used in a given project.  Few will just give blanket
>> approval to all boost libraries.
>
> I prefer a pragmatic approach here: Grab something from the internet,
> try to use it, check if library is actively maintained and estimate the
> chance this will be so for a while. If it works, make a code review and
> if no issues are risen, go on to the next problem.
>
>> The way boost was developed makes this practically impossible.
>
> Come on:
>
> a) Install a wiki on the intranet (5 to 55 minutes, depending on OS)
> b) copy the list of libraries from http://www.boost.org/doc/libs (3 minutes)
> c) add allowed/disallowed tags to all of them (1h, further discussions
> later)
> d) send email to team with link to wiki page (5 minutes)
> e) kill people during code review who do not adopt the rules (1 second)
>
> What kind of project leads are you working with?
>
>
>> Boost needs to advertise itself correctly and not pretend to be something
>> its
>> not.  Its simple a place for promising research libraries to live, to get
>> some exposure,
>> and possibly be adopted by the larger C/C++ community.
>
> No. Most boost libraries are pre-stage for an industry standard.
> No one is pretending here. They are serious about this.
>
>> Currently, boost provides the best place to do that, but it needs to be
>> honest with its users.
>>
>>
>>
>> 4) Many boost libraries seem more like they research projects.  The
>> prevailing view is that boost libraries push the envelope of what is
>> possible.
>>
>> This is universally considered a good thing and it is always interesting
>> to see what the best and brightest are up too.
>>
>> Unfortunately, boost pretends to be something else.  It pretends to be
>> a collection of libraries that meet your day to day needs.
>
> For me that is exactly what boost does.
>
>> Experience proves otherwise.
>
> Not for me.
>
>> The practical needs of large scale active projects are in conflict.
>>
>> Boost is very dogmatic and encourages a particalular style of development,
>> which is very template based.
>
> Modern C++. Yes. Not less than that for good reasons.
>
>> In the right hands, a heavy templated based project can work.
>
> No. That is not the point. Templates are used in order to obtain an
> extremely high level of abstraction while not sacrificing performance.
>
> Something like
>
>  Solver.AddPDE(ddt(rho) + ddx(rho*u) == 0);
>
> where the PDE is disasembled at compile time (!) and all its components
> are differentiated with regard to all variables again at compile time and
> the solver solves the problem within the theoretically achieveable minimum
> time.
>
>> In my experience, however, it takes many many iterations to get a template
>> based designed library correct and usable.  Many more iterations, in fact,
>> than the equivalent non-template design.
>
> Proof is missing here.
>
> Could you please rewrite boost::spirit without templates?
> Could you please rewrite boost::function without templates?
> Could you please rewrite boost::lambda without templates?
>
>> It is soo difficult, that I am very reluctant to use others template
>> based libraries.  I approach them with fear.
>
> Boost libraries or code outside of boost?
> Again my impression: it is more an issue of
> Modern C++ vs. Baby C++
>
>> That being said, boost::mpl and boost::spririt are wonderful
>> accomplishments and I use them regularly.
>
> So fear depends on author?
>>
>> 5) Macros.
>>
>> Need I say more.  The core boost libraries are full of macros.  So much
>> in fact, that close examination makes many of them practically
>> unmaintainable.
>>
>> I know there are practical reasons to use them.
>>
>> The main reason being compiler inadequacies.
>>
>> However, many developers question the value of a cutting-edge template
>> library that is full of macros.
>
> Value comes from usability. Do you judge a car by how you can drive it or
> not?
>
> Platform independence has its price.
> If you do not want to pay for it, then ... shrug.
>
>> What is the point of having the source code, when it take an experienced
>> developer many weeks to understand what the library is doing underneath?
>
> Maximum Portability. Usability. Performance.
>
>> What is the practical value of a library that can only be maintained
>> by the original developer(s)?
>>
>> This issue has surprised many, but has comes up often.
>
> Good Point. There are efforts to collect all the dirty tricks.
> A good start is:
> http://www.amazon.com/exec/obidos/ASIN/0201734842/
> http://www.artima.com/cppsource/foreach.html
>
>> If it takes more than a day to examine a libraries source code and
>> have some idea what its doing, its very dangerous to use.  This issue
>> will cause many to avoid complex templated macro-style boost libraries.
>
> I do not get this.
> It never takes more than an hour to get the key point of a boost library
> after reading the docs. C++ is not Knuth literal programming.
>
>
> Markus
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>