Boost logo

Boost :

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?

> * 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?


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


Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at