On Dec 5, 2006, at 4:58 PM, Kevin Lynch wrote:
I would go so far as to say that it is unacceptable for a serious library. Every extra requirement on client code that isn't absolutely necessary will dramatically reduce the potential userbase of your code unless it brings with it a set of stong benefits. And I think that you'll be hard pressed to show that this inheritance requirement brings ANY benefits, much less compelling ones.
That said, I would really love to see a library like this in boost, and I encourage Franck to push forward with development.
Ok, This is precisely the reason why I posted this sample code, as I was quite sure the consensus on a quadrature library would differ from this implementation. While I do agree that asking for inheritance explicitely is not in general a good thing, I think this code is fairly independent from this point. This bring me to the point raised by Michael Fawcett:
Why not just assume that the functor has typedefs for argument_type and return_type and document the details?
Yes, that is a solution, and the way I achieved that in my example was to derive from std::unary_function (maybe because I am too lazy to type two lines of code in my test functions ;-) ). Note that the quadrature code itself doesn't make explicit use of this so that the posted code works if you typedef result_type and argument_type them in your functor by hand. I am a bit sorry to have presented things the way I did. So let me try again ;-). This code DOES NOT require to derive from std::unary function, but it requires result_type and argument_type into be typedef'ed in their functors. I definitely appreciate the feedback, and I won't give up easily as I really wish to have a useful generic quadrature code ;-) Best Regards, Franck