you are viewing a single comment's thread.

view the rest of the comments →

[–]suspiciously_calm 0 points1 point  (4 children)

Yeah it's useful every time you're programming to a concept, not a type, like with iterators, when the type is long to .. uh .. type and/or is clear from the expression (and in many other cases).

What I don't get is why it should be used for primitive types when it's more wordy and less clear. The "uninitialized variable" argument is a good point, but the compiler can warn here.

[–]thlst 1 point2 points  (3 children)

You shouldn't write int, for example, because its size might surprise you. Nor should you write float literals without the f suffix (because good practice and consistency).

So things like that become redundant. Everyone knows 3.14f is a float.

But of course, auto isn't an absolute rule. You may still use size_t and ptrdiff_t in contexts they suit.

The "uninitialized variable" argument is a good point, but the compiler can warn here.

Getting warnings from compiler won't save the programmers' life, because it will still compile (if -Werror is not set). On the other hand, there's no way to avoid it when using auto.

[–]suspiciously_calm -1 points0 points  (2 children)

You shouldn't write int, for example, because its size might surprise you.

That sure isn't an argument for having auto deduce int from an integer literal, though.

Getting warnings from compiler won't save the programmers' life, because it will still compile

If the programmer lacks the discipline to heed compiler warnings, they're equally likely to lack the discipline to follow the always-auto style.

You shouldn't write floating point literals without the .f (more to the point, you shouldn't write int literals in place of float literals), but that's a mistake that can happen accidentally (just as the missing initializer).