Dean Michael Berris wrote:
On Thu, Jun 26, 2008 at 9:08 PM, David Abrahams <dave@boostpro.com> 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