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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-07-01 23:04:06

On Wed, Jul 2, 2008 at 12:03 AM, David Abrahams <dave_at_[hidden]> wrote:
> 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.
>

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.