Franck Stauffer ha escrito:
On Dec 5, 2006, at 4:43 PM, Neal Becker wrote:
Good to bring this up. Note that we've discussed this before (and I posted sample code).
I haven't seen your code yet, but you mention functors must derive from some base class. That's not desirable - and I doubt it's required.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
Hi,
Thanks for your answer...
To make that point clear, it is only required for static type checking of arguments and return types without having to use more than two template parameters.
If you only want to do static *checking* the cost may be unacceptable: after all, if some type does not match it'll trigger an error when instantiating your generic code --admittedly the error message will be more cryptic than provided by a BOOST_STATIC_ASSERT, but even so, cluttering the interface for static type checking reasons seems too much.
If you want to say it is not desirable for performance, I think deriving from std::unary_function costs nothing (since unary_function's only declare typedef's for return and argument types, there is not impact on calling the functor). The problem is that somehow I want the user to be explicit about those types.
I am of course open to any propositions to avoid deriving from std::unary_function that does not require a large template argument list.
You can use some traits-based technique. As for the result type, you can use the carefully thought out [boost|std::tr1]::result_of proposal: http://boost.org/libs/utility/utility.htm#result_of HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo