Iterators: Signs of Weakness in Object-Oriented Languages(home.pipeline.com)
home.pipeline.com
Iterators: Signs of Weakness in Object-Oriented Languages
http://home.pipeline.com/~hbaker1/Iterator.html
8 comments
Interesting. Your comment about C++0x closures inspired me to look it up on Wikipedia.
The verbosity of the fragment above is greatly reduced. You had to write 'sum' or 's' lots of extra times ('Summation(sum)', 'sum(s)', 'int& sum', and 'int& s'), and you won't have to do that anymore -- according to wikipedia your function will change in C++0x to:
Fortunately, it seems the C++ people even thought of that annoyance, and allow you to write:
The verbosity of the fragment above is greatly reduced. You had to write 'sum' or 's' lots of extra times ('Summation(sum)', 'sum(s)', 'int& sum', and 'int& s'), and you won't have to do that anymore -- according to wikipedia your function will change in C++0x to:
for_each( numbers.begin(), numbers.end(), [&sum](int n) { sum += n; } );
Fortunately, it seems the C++ people even thought of that annoyance, and allow you to write:
for_each( numbers.begin(), numbers.end(), [&](int n) { sum += n; } );
Of course, C++ already has std::accumulate, which is basically the same thing as a general fold or a summation, depending on which version you use. So, there isn't really much of a reason to write sum manually at all. :p
http://www.sgi.com/tech/stl/accumulate.html
http://www.sgi.com/tech/stl/accumulate.html
Indeed. I actually use this technique in my own code, and I feel like I'm laying down pipe all over the place to make sure the captured variable gets routed to the function object correctly. Once you do it a few times, it is obviously boiler-plate code and obviously a hindrance to momentum.
Conveniently ignored Smalltalk, which at the time, would have been seeing a lot more use than it does now.
I missed the date of the article at first, it wasn't until I looked at the C code and had to double take it, because it wasn't ANSI C, and my initial reaction was "hang on wait a minute" then checked the date on the article.... yeah.
I missed the date of the article at first, it wasn't until I looked at the C code and had to double take it, because it wasn't ANSI C, and my initial reaction was "hang on wait a minute" then checked the date on the article.... yeah.
It's worth reading the Abstract Heresies' entry that turned my attention to this paper: http://funcall.blogspot.com/2010/05/c-vs-lisp.html (After giving it a thought I posted this entry to HN too, as I probably should have done in the first place... :))
The date is interesting, 1992 - it would still take years for Java to implement it...wrong.
The date is interesting, 1992 - it would still take years for Java to implement it...wrong.
It seems odd that he complains about lack of local (modifiable) state while at the same time talking up the advantages of pure functional programming. It's painful to have to explicitly capture state instead of depending on a closure to do it, but you can do it, and somewhat nicely using objects in C++.
Also, is it not right that iterators were introduced in C++ largely to allow generic functions across arrays and other data structures?
Finally, do iterators necessarily imply statefulness? Doesn't seem like it. Taking + 1 as "successor": double sum(const double* start, const double* end) { if (start == end) { return 0.0; } else { return *start + sum(start + 1, end); } }
Also, is it not right that iterators were introduced in C++ largely to allow generic functions across arrays and other data structures?
Finally, do iterators necessarily imply statefulness? Doesn't seem like it. Taking + 1 as "successor": double sum(const double* start, const double* end) { if (start == end) { return 0.0; } else { return *start + sum(start + 1, end); } }
Something about the writing style in the Introduction section reminds me of this classic Dilbert strip: http://tomayko.com/writings/that-dilbert-cartoon
It seems these are lessons we must perpetually relearn.
[deleted]
C++0x lambdas will generate code very similar to this. The need to explicitly define a named struct/class and function object is an obvious weakness of this technique.
Although I do agree with his overall point, which is that the need to use iterators for all sequences is a code smell. It forces the programmer to work at a lower level when they often just want to say "Perform this operation on my data."