C ++ iterators considered harmful?

Question

At today's Boost Library conference, Andrei Alexandrescu , the author of Modern C ++ Design and Loki C ++, gave an interview entitled “Iterators Must Go” ( videos , slides ) about why iterators are bad, and he had the best solution.

I tried to read the presentation slides, but I could not get much from them.

• Are iterators bad?
• Is his replacement really better?
• Do C ++ developers implement their ideas?

Answer 1

First, to answer your questions:

• No. In fact, I have argued elsewhere that iterators are the most important / fundamental concept of computer science. I (unlike Andrei) also think that iterators are intuitive.
• Yes, definitely, but this should not be a surprise.
• Hm. Looking at Boost.Range and C ++ 0x - right?

Andrei is a big contribution here simply to say: to abandon the concept of iterators altogether, see ranges not only as a convenient wrapper, but as the main construction. Other languages ​​have already done this (many of Andrei's concepts are simply echo .NET LINQ or Python iterators), but they all offer only output ranges. Andrey talks about different types of ranges, as well as the usual categories of iterators.

In this light, it is strange that he begins by mocking the arbitrariness of these categories of iterators.

I also think that his examples are disabled, especially copying his files: yes, the iterator option is a huge improvement over the 1975 code. It reduces the loop with the complex interrupt condition to a single statement. What he really cares about here is just the syntax. Well, excuse me: we are talking about C ++ here - of course, the syntax is ugly. And yes, using ranges here is an improvement, but only syntactically.

I also find that the Andrei find implementation is disabled. What it actually defines is the DropUntil operation (naming is complicated!) From LINQ. The find operation should really return a single or null element (or an iterator!). Rejecting iterators here does not help, in my opinion, since we may want to change the value directly, rather than copy it. Returning the singleton range here only adds overhead without the benefit. Following this path of Andrey is bad, because then the name of the method is simply incorrect and misleading.

Nevertheless, I practically agree with Andrei in almost all matters. Iterators, being my concept for pets from computer science, certainly represent a great syntax load, and many ranges (especially infinite generators) can (and should) be implemented without them.

Answer 2

• Most of us just use them in what have become well-known idioms, for example for loops, to go through std :: vector. The developer reads it and knows what is happening. In our daily coding life, iterators are not good or bad, they are just "what does its job."
• Probably yes.
• I do not think so.

Answer 3

Andrey can sometimes be a little provocative. Iterators are a reasonable concept and quite fundamental in the sense that bits are. But just as most bits in C ++ are not bools, but part of larger types, most iterators should be solved at a high level. Andrei is right that the correct level for this is a range object. But not all ranges are correctly displayed as iterator ranges, as istream_iterator shows. It is easy to crack the artificial end iterator. However, I do not think that his ideas will be picked up by the implementation. C ++ 1x will matter as C99.

Answer 4

I agree with him that iterators are mostly inferior to ranges, and I don't know if "something better" will get.

“Good is the enemy of the best,” plays a lot here, as is usually the case. Iterators are useful and firmly rooted, so it’s hard to see if something better than ranges can force them out at reasonable intervals.

Answer 5

C ++ 0x is already taking its first steps:

• Rvalue links solve some problems with handling containers in ranges. Ranges have been added to the base library
• including range concepts

Going to ranges without losing any iterator functionality (think of all combinations of iterator categories, constants, and rvalue-ness) is difficult, especially if you are trying to influence infinite and mutable ranges.

Answer 6

• No, they are not bad, in fact this is a very smart idea. However, they are not perfect, and there is an opportunity to improve the iterator concept.

• It solves many problems with iterators in real life. For example, it is tiring (also error prone) in many cases to request two separate objects, iterators, from one container, and then transfer them as two more separate objects to the algorithm. Why not walk around a single object? Even std::pair<iterator, iterator> will make for a rough range that is easier to manipulate - one object, not two. It is also recommended that you consider a range is an iterator . This is actually what Andrey offers. By the way, some of these problems have already been resolved by Boost.Range .

• I would expect this to happen, but it will not be a revolution, but evolution.

Answer 7

I think we should use ranges next to iterators, i.e. we must choose the path of evolution, not the revolutionary way.

Answer 8

Isn’t Andrei trying to do some kind of hidden marketing for the D language (he is currently working with it) ...?

Andrei claims that the containers are fine, but the iterators are ugly, not intuitive, error-prone and dangerous, they are difficult to implement (well, it seems this last seems to be true ...) And what we have in C ++ ... pointers? Aren't they ugly /.../ dangerous? But we hugged them happily and lived with them.

Which one is more intuitive:

 for(auto i=foo.begin();i!=foo.end();++i) bar(*i); 

or

 for (auto r=foo.all(); !foo.empty(); foo.popFront()) bar(r.front()); 

The concept of iterators can be supplemented by ranges and other ideas, but I think that they have their place and will not be replaced.

Answer 9

• Sometimes
• Maybe,
• It does not seem, at least not for many years.

Answer 10

Like any API or function, if misused can complicate many identification problems. Iterators were used in many projects, but always maintained the necessary care in accordance with their characteristics. Its use must be preceded by a good understanding of their limitations. Iterators can be very useful if the user is correct.
These issues are related:
Is there any way to check if an iterator is really? Should I prefer iterators over const_iterators?

Answer 11

I do not agree with Andrei and Konrad and with myself :-)

The most fundamental concept is the interface, not the iterator, and this is pretty obvious in any work that someone does today (as for the cross-library, cross-language, cross-compiler, cross-OS, cross-platform, you rename him:-)

Neither the iterator, nor the range (other than using the source level) offers nothing more pure and simple, non-intrusive or intrusive, not general or general, not unique or unique: a pointer! A clean pointer to typed data is simply made universal, and you can make data mutable or immutable, and many others. The whole interface is another level of indirection, although it is still friendly to machines and compilers of all kinds, and also much safer by dropping iterators and using range to implementation details.

To this extent, IEnumerable and IQueryable make half the “right” TM, but they are clearly inferior to their concepts of iteration and much more than what you can do with STL, maintain control and so on and so forth (but otoh, they have better metadata and, therefore, a better, cleaner model). A point with interfaces allows you to create any abstraction that you want and satisfy, but probably contradictory, but it’s essentially brainless: optimal and temporary or neutral representation of data and compilation time code (especially important for algorithms and compilers and virtual machines, and what not ),

You can even optimize it for "dynamic" / component systems down to "runtime" inline (HotSpot VM screw :-) .. To this extent, the progress until 1975 is minimal, as can be seen from the huge workload in interop (this is where you look , including this site, its use of proprietary and open technologies, etc., in the idealism of computer science, this type of interaction "work" should not exist if it).

Answer 12

I think that C ++ developers will receive full support for full support for C ++ 0x without implementing new, non-standard paradigms.

Answer 13

The only argument I can see from this view is the inability to define ranges, and the C ++ 0x proposal “Range for approval” seems to fix this problem to some extent. perhaps this should not be an argument as to whether iterators should use / not use at all, but moreover, in what situations should they / should not be used?