On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
One point of clarification: opApply isn't going to be deprecated
anytime soon, is
it? It seems like ranges still have a bunch of rough edges, and
although I like
the idea in principle, I'm only willing to convert to ranges if I can define
iterable objects with the same level of syntactic sugar as opApply
gives me. For
simple cases this is already true and I have begun converting some stuff.
However, for more complicated cases, opApply is still a lot more flexible.
opApply isn't going away. For one thing, it works very well with
recursive data structures.
So besides performance, what advantages does using ranges instead of
opApply for
iteration over structs/classes offer? According to some testing that I just
finished on the hash table implementation I was talking about earlier
today, the
penalty for using opApply is small enough that, if using ranges
requires a bunch
of extra bookkeeping overhead that opApply doesn't, then opApply can
reasonably be
faster.
Speed is a small part of the equation, in fact a perk only. Ranges are
composable; you can combine them to e.g. do parallel iteration over two
ranges. Ranges really open std.algorithm to all data structures. I find
opApply incredibly obtuse and fostering bad design. I wish it goes away.
Andrei
But if it goes away, that'd prevent a lot of cool things that could be
done with foreach. You could create a template that automatically
distributes iterations to various threads with very little code
(assuming the loop delegate is pure):
foreach (i; paralelize(myArray))
doSomethingComplicated();
All the complexity would lay in the opApply. You can't do this with ranges.
Other possible things involves a rudimentary profiler (checking for the
elapsed time at each loop iteration), or a progress monitoring template
(notifying another thread of the progress of a particular task).
foreach (task; progessUpdater(timeProfiler(listOfTasks)))
{ ... }
For basic data manipulation algorithms, ranges are better. But for more
fancy stuff, opApply still rules.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/