Hacker News Reader

Comment by Animats | Hacker News Reader

Well, the first bug is at

    for ( auto i = results.begin( ); i < results.end( ); ++i )

which should be

    for ( auto i = results.begin( ); i != results.end( ); ++i )

This will work on all the standard collection types. If "results" is some non-ordered type, such as a list, the first form won't work.

The reason for "auto" is that writing the type expression for an iterator is bulky, and quite messy in some situations involving generics. There were some situations where you needed "decltype". That was just too obscure.

Newer languages offer auto-type implicit type declaration by default. Both Go and Rust do this. It makes programs easier to write, but harder to read.

When this idea was first being kicked around on the C++ standards newsgroup, I proposed that the keyword "let" should be used. But adding a new keyword might break existing code, so "auto", which wasn't used much, was repurposed.

View on HN

Writing code that breaks if someone changes the type of the collection is not a bug in any sense that I ever saw the word used in. At most it's a failure to make the code as pliable as one might desire it to be - but the author is not very likely to value the ability to easily replace an array with a list (it appears he'd be concerned about the performance implications and would want to review all the relevant code anyway.)

Also in reality making sure that your arrays can be replaced with lists means you can't store indexes into the array but instead you must store iterators, which sucks when you have to declare them (auto won't work in many contexts and typedef will expand into the ugly underlying type in many contexts), and sucks when you have to print them ("5" or "342" reads better than whatever garbage you'll have to resort to when printing out an iterator, and it persists better between program runs and across platforms, too.) So if I have an array/vector I'd rather not try to pretend that it's a "non-ordered collection" until I absolutely ought to use random access; I'd just treat it as an array/vector from the start.

So I guess what I'm trying to say is, not only is it not a bug but the attitude of people who write such non-bugs has many advantages.

(And BTW caring about performance is not the main point. A nice thing about your typical dynamic language is that there's not much gratuitous polymorphism. You get a few basic collection types and you use these and most code doesn't jump through hoops to be able to replace the standard collection type with some polymorphic replacement only satisfying a subset of the interface. So-called "type-rich" programming gets gnarly, I prefer "type-poor" on any day. Which isn't the main point, either, the main point is that things that work nicely in practice (like treating arrays as arrays) matter more to me than things that sound "right" from an abstract viewpoint (like being able to replace your collection types with other types.) And calling it a "bug" is, I guess it kinda bothers me and hence the wall of text...)

If you use ".end()" on an C++ standard array collection, what you get is not the array size. You get an invalid iterator pointing one element past the end of the array, which tells you when to stop.

Most newer languages have built-in syntax for "iterate over collection". C++ does not, leading to somewhat clunky constructs like this. It's ugly, but that's where C++ ended up.

(I personally think that the C++ committee went way too far in making the template fanatics happy. It's neat that C++ templates, being a general term-rewriting system, allow arbitrary computation at compile time, but templates are a terrible programming language. More recently, it worries me that Rust is going too far in that direction.)

> Most newer languages have built-in syntax for "iterate over collection". C++ does not.

Huh? C++11 includes a range for:

    for ( auto i : results )

Right; I'm behind on C++ versions.

What specifically don't you like about templates? Curious

  > it worries me that Rust is going too far in that 
  > direction.

Rust is making no steps at all towards anything akin to templates. Can you elaborate?

let is traditionally used for expressions, not types.

Rust uses "let" to declare local variables using implicit typing.

    let one_to_one_hundred = (1..101).collect::<Vec<_>>();

What do you mean? Here, "auto" is being used to define a variable, just like the way "let" does in other languages.

    for (let i = results.begin( ); i != results.end( ); ++i)

This matches the use of "let" in Haskell, Lisp, Rust, ES6, etc.

(Note that when I say "variable" in this context, I am using it as the hypernym, not in the sense where it denotes only mutable variables.)

What I mean is that for me, 'auto' in C++ means something like 'automatic type', e.g. it stands in for the actual type, whereas let x = some_expr means something else - it doesn't really say anything directly about the type of x.

Reply on news.ycombinator.com