From: Franck Stauffer (franck_at_[hidden])
Date: 2006-12-05 11:23:26
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
> ANY benefits, much less compelling ones.
> That said, I would really love to see a library like this in boost,
> I encourage Franck to push forward with development.
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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk