Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 12:03:30

Dean Michael Berris wrote:
> On Mon, Jun 30, 2008 at 9:37 PM, David Abrahams <dave_at_[hidden]> 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