Something I never thought I’d use when I first learned about it is the keyword auto. It was first introduced in C++11 and has been a hot topic for a few years now.
Briefly, if you haven’t heard of it, auto is a keyword that lets the compiler decide a variable’s type. Usually, what happens is that people instantly start thinking about Python’s variables or JavaScript’s “var/const”, where variables can be any type at all.
That’s not really the exact same case in C++; we instead use auto to let the compiler pick the type, and when the code is compiled, only objects of that type can be stored (which doesn’t mean that we can mix freely at runtime).
auto a = "Hello World!";
auto b = 3;
a = b;
// main.cpp:15:9: error: invalid conversion from ‘int’
// to ‘const char*’ [-fpermissive]Benefits
The benefits of using auto are that there’s less typing, but wait, it’s not typing in the way that most people think when I say “less typing”. As programmers, we should generally not shy away from typing code; it’s after all our job in the end. No, but what I mean by less typing is that in cases where you refactor the code, fewer updates are needed.
Furthermore, the compiler usually knows better in any case. Deduction from the input that it gets is quite easy for the compiler, while humans usually struggle to get the types correct.
In the case that you want a specific type, simply construct that type as follows and pass it to the compiler; it’ll do its job and deduce the same type, with the bonus that the value you enter will always be checked if it fits the type.
auto a = float{1.23f}; // OK
auto b = double{1.321}; // OK
auto c = int{1.23}; // narrowing conversion of ‘1.23e+0’Drawbacks
But as with everything, nothing’s for free. There’s a large drawback to using auto: readability on new codebases. In case you work on a new codebase, or the same as before but later when you’ve already forgotten everything, having auto everywhere will not help.
There’s the case that you can always look it up with the help of your IDE’s built-in find reference or deduction from the variable. This is of course true, but not in all cases and there’s a high likelihood to slow you down greatly while getting back into a codebase.
But we can actually do something about this: naming the variables and functions better now becomes a task for you as a programmer to keep the benefits with fewer of the drawbacks. Basically, don’t name things with shorthand; e.g., “data” or “xyz” doesn’t help much compared to “data_list” or “xyz_float”.
Now isn’t that just an unnecessary lot of typing when I could’ve just put that as the type in the first place, you might say? Then you probably haven’t understood the point of auto in the first place, since now the name is decoupled from the type and the compiler decides what’s actually the correct type.
The variable name could even be wrong, i.e., a float could be called “my_int” because someone changed the type, and the program would’ve still worked as intended. It’s only when someone tries to pass the value and gets a narrowing conversion warning that it’s discovered, and then a quick search and replace would fix the misleading name. A bit quicker compared to going around and changing the type everywhere 😉.
Best regards,
William Bergh
Leave a Reply