From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-10-02 12:03:25
On Tue, Oct 01, 2002 at 10:31:50AM -0700, Powell, Gary wrote:
> I vote for inclusion.
> I reviewed the code, and wrote some tiny test code to sort of play around with it and things seem to work as expected. The documentation is fine for my purposes.
Good to know that you haven't found any problem using the code. May I
ask what platform/compiler?
> While this set of algorithms is not (for me) a common need, it seems common enough to include in a boost algorithm library. I understand that in games, one might one the farthest and the closest set of points on an object and making one pass rather than two is a good optimization.
I didn't think of that use. The more common use I thought of was
bounding boxes, but then the library does not offer enough. It would
require combinable accumulators. I've written a rationale. It's true
that closest/farthest offers another kind of bounding box (an annulus)
which may be useful.
> I think I would have preferred that the last_min_element et.al were policy generated algorithms but not having enough experience with these algorithms and policy algorithms in general should not preclude acceptance at this time. I also do not have time to write a policy set and try them, so having a set of working algorithms is worth a lot more to me than some other yet to be coded set.
I wrote a rationale about that too. It would be nice, but would depart
from the standard interface for min_element. Nevertheless, if minmax_element makes
it into the C++ standard algorithms, as intended, then I'd be happy to
resume work and provide a policy version which is backwards-compatible.
> Note to self:
> If accepted write cover classes to make it work with the lambda library.
Thanks for mentioning it. I'll look into it, although I'm not familiar
with cover classes. If you elaborate, I'll be faster on the job.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk