Michel Fortin wrote:
On 2009-04-26 11:46:51 -0400, dsimcha <dsim...@yahoo.com> said:
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
Hum, are you saying opApply superior when it comes to iterating in a
tree? It seems that with opApply you could use the stack by recursively
calling opApply with the given delegate on each one of the branches.
Exactly. On the other hand, you lose a lot of flexibility with
opApply. If you
tried to port most of std.range to operate on the opApply interface
instead fo the
forward range interface, I doubt you'd get very far.
IMHO, though, opApply should *not* be deprecated. opApply and ranges
attempt to
solve similar problems, but not the same problem. Ranges attempt to
solve the
problem of iterating over some object with maximum flexibility from
the point of
view of the user of the object. opApply attempts to solve the problem of
iterating with maximum flexibility from the point of view of the
implementer of
the object. In some cases, like the one you just described, the
latter can be
better.
Indeed. I certainly agree that both ranges and opApply have their place.
So what the implementer can do with opApply is write an optimized
iteration algorithm for use with foreach. Which may mean that when both
opApply and ranges are available for generating foreach's code, the
compiler should favor opApply. Currently, I believe it's the reverse.
I think, all other things being equal, that opApply tends to be slower
than iterators.
Andrei
