2 Jul
2008
2 Jul
'08
3:04 a.m.
On Wed, Jul 2, 2008 at 12:03 AM, David Abrahams <dave@boostpro.com> wrote: > 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. > Ok. >>>>> 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. > Yeah. >> [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 > I guess then this should be one of the important parts that really need to get in there. >> 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 > After reading some of the other emails in the thread, I'd think there are already some avenues worth exploring as far as getting Phoenix 2/3 is concerned -- which can only mean good things. :D >>>>> 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 > Nice. >>>>> 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 > Ok. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.