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