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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-07-01 00:47:44

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.

>>> 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.