

Iterators: Signs of Weakness in Object-Oriented Languages - pcof
http://home.pipeline.com/~hbaker1/Iterator.html

======
scott_s
While C++0x will have proper lamdbas and closures (I've said this how many
times in the past few weeks?), I think it's worth noting the "proper" way to
emulate a closure in C++ is with a function object. Example:

    
    
      struct Summation {
        int& sum;
        Summation(int& s): sum(s) {}
        void operator()(int n)
        {
          sum += n;
        }
      };
    
      vector<int> numbers;
      int sum = 0;
      // give numbers some interesting values
      for_each(numbers.begin(), numbers.end(), Summation(sum));
      cout << "sum of all numbers: " << sum << endl;
    

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."

~~~
lincolnq
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:

    
    
        for_each( numbers.begin(), numbers.end(), [&sum](int n) { sum += n; } );
    

Which is semantically much less to think about. It also still has the feature
/ annoyance (?) of having to specifically identify which variables to capture
from the environment ('sum', as a reference; it seems you can capture
variables by value too).

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; } );
    

capturing references to all variables in the enclosing scope. Neat!

~~~
Figs
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>

------
malbs
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.

------
pcof
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.

------
util
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); } }

------
huhtenberg
PDF version -
[http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=D07...](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=D0759C8E59B0FC3EF23C2E6ED17A88F3?doi=10.1.1.25.1018&rep=rep1&type=pdf)

------
aaronbrethorst
Something about the writing style in the Introduction section reminds me of
this classic Dilbert strip: <http://tomayko.com/writings/that-dilbert-cartoon>

------
ct4ul4u
It seems these are lessons we must perpetually relearn.

