Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-30 09:37:10

Dean Michael Berris wrote:
> 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). 

OK, but it's not just about problems.

> 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 don't think there's anything "coupled" about coordinating foundational
parts so they interoperate properly.

>> Here are the parts and topics that I see as being in the category:
>>
>> result_of

* Too hard to define result<> templates for polymorphic function objects.

* A whole spate of questions that came up in
http://article.gmane.org/gmane.comp.lib.boost.devel/173370 were not
answered with a page of documentation, utility library, or other
facility.  I still don't know what the upshot was

>> BOOST_TYPEOF

* Doesn't coordinate with result_of

>> range_ex

* Not in Boost.  Should have pipe syntax.  Maybe should use expression
templates and be lazier.

>> BOOST_FOREACH

* We don't have range_ex ;-)

>> our own implementations of std::containers (in interprocess, IIRC)

* Not well-known.
* Not in a general place (bound to interprocess?)
* Ought to support move semantics

>> lambda/phoenix/bind

* Incompatible placeholders
* Been waiting for the lambda/phoenix merger forever
* Lambda has lots of limitations and gotchas that we can improve on now
* Phoenix 2.0 not in Boost

>> move semantics

* Not supported by many foundational Boost types that could benefit
(e.g. shared_ptr)
* No general move semantics library in Boost

>> Boost.Iterator

* Needs an update (e.g. "new iterator concepts" have to go -- C++0x
resolves that differently by simply allowing proxies everywhere)
* Several important fixes and features needed

>> Boost.Algorithm

* Should support ranges, move semantics, segmented iterators, property maps

>> segmented iterator support (http://lafstern.org/matt/segmented.pdf)
>> property maps

The above are just related to the rest of them.

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

* More "it just works out of the box" experience
* More efficiency!

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

Something like that.  I guess efficiency is the other big concern.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com