Just a quick note, regarding this part:QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunthanks!I'm not sure if this is correct, but here is an idea I had:I've quite often used "std::sort" "std::map" etc with my own user-defined compare like below. Could you do the same for the f() in your example and eliminate the need of boost::function?It could be possible but why would you want to eiminate the need for boost function? it is a *protocol* and already subsumes any kind of function you throw at it. You can define any comparitor and use it to instantiate the boost function. It is the same as .NET delegate type vs delegate instance.Do you want to make the s/w so generic that even boost function has been templated away? If so, then the code will be very difficult to understand.and this part:template <typename ReturnType, typename T, typename FO>struct MultipleRole2{ // Simple pipes and filter with a common data //boost::function<ReturnType (T& x)> f; // 'Intrinsic' compute function FO f; // ...}IMHO, some of the difficulty will disappear when using a clear, descriptive naming convention: ReturnType is an example, very good!Instead of "FO" I'd suggest a name corresponding to a concept that FO models -- in this case, the point is not that it's a function object (it could be anything callable, incl. boost::function (or std::function in C++11!), C-style fn ptr, and fn obj, too!) -- and at the same time it's nice for it to be refined enough s.t. the arity is clear -- so, perhaps UnaryOperation? Then, users familiar with the STL should immediately recognize the name and the concept (already documented for us by the SGI, so that's another plus :]) and know what's going on."The basic function object concepts are Generator, Unary Function, and Binary Function: these describe, respectively, objects that can be called as f(), f(x), and f(x,y). (This list could obviously be extended to ternary function and beyond, but, in practice, no STL algorithms require function objects of more than two arguments.) All other function object concepts defined by the STL are refinements of these three. "
http://www.sgi.com/tech/stl/functors.ht ... tmlInstead of T perhaps Scalar or even something along the lines of UnaryOperation::ArgumentType -- the second choice is an example of constraining the type to an associated (here: dependent) type, which was actually a subject of a heated discussion on Boost Dev as "Boost.Algorithm design question":
http://boost.2283326.n4.nabble.com/Boos ... 76424.html(with both sides making some good points -- incidentally, Cuch & outrun: since we're likely having to (re)make this choice, what do you think is a good design decision here and why?)Of course if we decide on dependent types, then we could go further and specifically say UnaryOperation::ReturnType instead of ReturnType, but that's subject to discussion...