auto is the chess pawn of C++. Ignored in the opening. Underestimated in the middle game. Then modern C++ took it to the last rank — and promoted it to queen. What once looked like an ordinary keyword has become one of the most practical and powerful features in modern C++. Today, auto helps developers write code that is: • cleaner • safer • easier to maintain • more expressive with complex types, iterators, lambdas, and templates The real value of auto is not “typing less.” It is about improving readability where the type is obvious, reducing redundancy, and letting the code focus on intent. Used well, auto is not laziness. It is modern C++ maturity. #cpp #moderncpp #softwareengineering #programming #developers #coding #cplusplus
"Used well, auto is not laziness." No, computer languages should always be strongly, statically, and manually typed. The existence of auto is an abomination. So is typecasting. When you write code you should know exactly what every variable is and be able to declare it explicitly, and it should never be able to change.
Readability is having types visible
In my opinion, by using auto, you allow the compiler to determine the types handled by a function. You might expect one type, but the compiler could deduce a different one; while this may not trigger a compilation error, it can lead to unexpected behavior. Ultimately, you lose control over the types. That is why I believe auto should be banned or restricted solely to iterators. To me, auto is like a rug that hides poor design. auto& data = manager.get_all_data(); Although this may look 'clean' and easy to read, it masks a flawed architecture. In this case, data is actually a std::map<int, std::list<std::string>>. Such a complex type should have been replaced by one or more abstractions to reduce overall complexity.
yea agreed. to add on one small but helpful detail about auto is how it enforces initialisation of variables. e.g. std::array<bool> flags; // vs auto flags = std::array<bool>{}; the first line could lead to usage of uninitialised flags, resulting in unexpected behaviours in our code. whereas with auto this is mitigated because we are required to initialise at declaration.
Yes. Agree. Now, consider this: auto a = 5; auto b = 6; auto c = a / b; auto d = 12 / c: Once you got pegged by this, you will think twice before you type "auto".
I was more under the impression that "auto" was used when the type is obvious "for the compiler" but not for the poor human that uses all those stuff. I mean, I don't even know what would be the type of a lambda. Whereas in java, I just don't use the "var" keyword that is Java's "auto". So even if auto has not been designed for lazyness, in practice it will be mainly used for this.
auto is used when developer do not remember or know exact type name due to using templates. auto could be used if type is not important in very narrow scope. Clean code is avoid using templates.
The post you shared treats C++ like a scripting language. When building industrial-grade machinery. In machinery, ambiguity is a bug. auto is often considered a technical debt. It causes silent failures. Also, it is the main cause of readability degradation.
Auto is only cleaner in so far as it is only 4 characters to write. Auto is, if anything, less safe, especially considering function and operator overloading. By changing what a variable is initialized to, you may have just completely changed your program, without warning, while correcting the behavior may be upstream, not downstream. Auto is harder to maintain for the previously stated reason, types then are no longer contained by variable, they then may cascade without warning. It is only easier to maintain in the sense that you no longer see errors. `more expressive with complex types, iterators, lambdas and templates` only by virtue of not having to type it. Having to read it, you literally just made everyone's jobs harder. Also, if you have such complex types, reconsider. Implicit is always worse than explicit.