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

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-26 09:08:32

Mathias Gaunard wrote:
> Steven Watanabe wrote:
>> Can't you use result_of?
> 
> As far as I can see, the current boost::result_of implementation doesn't
> use decltype or typeof.
> I suppose implementing decltype on top of typeof is not a big problem
> (you only need to check whether the expression is a reference or not)
> however both have problems with mangling when used in a return type, at
> least in GCC.
> That basically means you can't always rely on them working. I thought
> decltype didn't have those mangling problems, looks like it is a regression.
> 
> As for the correct way to do that, I suppose it should be possible to
> tell boost::result_type with a macro definition to use Boost.Typeof,
> which in turn can use either native or emulation.
> 
> However range_ex only forwards algorithms and adaptors to Boost.Iterator
> and maybe the standard library. Maybe it's these that ought to use
> boost::result_of in the first place?

I've been thinking for a long time that we need to develop a coordinated
approach to developing some of these more "basic" facilities.  We have
too many great bits and pieces that don't quite interoperate as well as
they could.  This was driven home for me recently when I taught a course
on Boost with hands-on workshops and the number of pitfalls  that people
(including me!) ran into was just too high.  In order to really make the
case for the power of library use, it needs to be easier to write
expressive C++.

I'm not sure exactly how to proceed from here.  Maybe the first thing is
to develop a list of things in (or that should be in) Boost that seem to
fall into this category, because I don't really understand the rules my
brain has used to decide the category boundaries.  Maybe after that we
need a "library domain maintainer" or something who can see to the
coordination of these things... but let's not get ahead of ourselves.

Here are the parts and topics that I see as being in the category:

result_of
BOOST_TYPEOF
range_ex
BOOST_FOREACH
our own implementations of std::containers (in interprocess, IIRC)
lambda/phoenix/bind
move semantics
Boost.Iterator
Boost.Algorithm
segmented iterator support (http://lafstern.org/matt/segmented.pdf)
property maps

Thoughts?
-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com