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:
* 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
* Doesn't coordinate with result_of
* Not in Boost. Should have pipe syntax. Maybe should use expression
templates and be lazier.
* 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
* 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
* No general move semantics library in Boost
* 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
* 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk