Boost logo

Boost :

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-06-29 23:16:27


On Thu, Jun 26, 2008 at 9:08 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> I've been thinking for a long time that we need to develop a coordinated
> approach to developing some of these more "basic" facilities. We have
> too many great bits and pieces that don't quite interoperate as well as
> they could. This was driven home for me recently when I taught a course
> on Boost with hands-on workshops and the number of pitfalls that people
> (including me!) ran into was just too high. In order to really make the
> case for the power of library use, it needs to be easier to write
> expressive C++.
>

What would be helpful I think would be a statement of exactly what the
problems are with the great bits and pieces and in what particular
context they are considered problem(s). I think it would be easy to
agree that we'd love to have everything in Boost work like it new
every other library in it, but that makes Boost more a Framework than
a library collection. I don't necessarily think that would be a Bad
Thing, but rather too close a coupling for my taste.

> I'm not sure exactly how to proceed from here. Maybe the first thing is
> to develop a list of things in (or that should be in) Boost that seem to
> fall into this category, because I don't really understand the rules my
> brain has used to decide the category boundaries. Maybe after that we
> need a "library domain maintainer" or something who can see to the
> coordination of these things... but let's not get ahead of ourselves.
>
> Here are the parts and topics that I see as being in the category:
>
> result_of
> BOOST_TYPEOF
> range_ex
> BOOST_FOREACH
> our own implementations of std::containers (in interprocess, IIRC)
> lambda/phoenix/bind
> move semantics
> Boost.Iterator
> Boost.Algorithm
> segmented iterator support (http://lafstern.org/matt/segmented.pdf)
> property maps
>
> Thoughts?

How about we first collect the problems you encounter and what other
people already encounter with the specific libraries you've listed
above -- and what precisely or roughly you'd like to achieve with
coodinating the effort(s) of the above.

Would it be safe to say you'd like to coordinate these to achieve true
"expressive C++" with libraries?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

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