On Mon, Jun 30, 2008 at 9:37 PM, David Abrahams <dave@boostpro.com> wrote:
Dean Michael Berris wrote:
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.
Right, but I was stating this more in terms of dependency between/among components.
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.
Isn't this one of the issues the EGG library is supposed to address? [snip]
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.
This is scheduled already for review right? [snip]
our own implementations of std::containers (in interprocess, IIRC)
* Not well-known.
I agree.
* Not in a general place (bound to interprocess?)
Should there be a Boost.Containers library where we distill all the containers implemented in a myriad of libraries? Multi-Index and Bimap come to mind...
* 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
Is Phoenix 2.0 not in the review queue yet?
move semantics
* Not supported by many foundational Boost types that could benefit (e.g. shared_ptr) * No general move semantics library in Boost
Should we borrow the ASL move library implementation?
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
Interesting... Do you have a list of important fixes and features needed?
Boost.Algorithm
* Should support ranges, move semantics, segmented iterators, property maps
I agree.
segmented iterator support (http://lafstern.org/matt/segmented.pdf) property maps
The above are just related to the rest of them.
Should Boost.Iterator have a 'segmented_iterator' type?
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!
When you say "just works out of the box", do you have a concrete use case that would generally shed some light as to a possible specific context you want things to "just work"?
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.
Ok. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.