1 Jul
2008
1 Jul
'08
4:03 p.m.
Dean Michael Berris wrote: > 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. I don't think there needs to be such dependency for the most part. You can support result_of without including its header. >>>> 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? perhaps. IIRC it was not accepted. > [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? Perhaps > 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... Definitely >> * 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? I don't know >>>> 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? No need to borrow; Adobe has told us we're welcome to move it into 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 >> > > Interesting... Do you have a list of important fixes and features needed? See Trac. > Should Boost.Iterator have a 'segmented_iterator' type? Not exactly, but I suppose any facility for supporting segmented iterators should live in the iterator lib, yeah -- Dave Abrahams BoostPro Computing http://www.boostpro.com