Prior to C++11, the auto keyword was probably the least used keyword in C++. However, C++11 and newer language standards have given new life to the auto keyword. We’ll cover many of those uses here.
Consider the following statement:
|
1 |
double d{ 5.0 }; |
If C++ already knows 5.0 is a double literal, why do we have to explicitly specify that d is actually a double? Wouldn’t it be nice if we could tell a variable to just assume the proper type based on the value we’re initializing it with?
Type inference for initialized variables
When initializing a variable, the auto keyword can be used in place of the type to tell the compiler to infer the variable’s type from the initializer’s type. This is called type inference (also sometimes called type deduction).
For example:
|
1 2 |
auto d{ 5.0 }; // 5.0 is a double literal, so d will be type double auto i{ 1 + 2 }; // 1 + 2 evaluates to an int, so i will be type int |
This also works with the return values from functions:
|
1 2 3 4 5 6 7 8 9 10 |
int add(int x, int y) { return x + y; } int main() { auto sum { add(5, 6) }; // add() returns an int, so sum's type will be deduced to int return 0; } |
While using auto in place of fundamental data types only saves a few (if any) keystrokes, in future lessons we will see examples where the types get complex and lengthy. In those cases, using auto can save a lot of typing.
Type inference for functions in C++14
In C++14, the auto keyword was extended to be able to deduce a function’s return type from return statements in the function body. Consider the following program:
|
1 2 3 4 |
auto add(int x, int y) { return x + y; } |
Since x + y evaluates to an int, the compiler will deduce this function should have a return type of int. When using an auto return type, all return statements must return the same type, otherwise an error will result.
While this may seem neat, we recommend that this syntax be avoided for normal functions. The return type of a function is of great use in helping to document for the caller what a function is expected to return. When a specific type isn’t specified, the caller may misinterpret what type the function will return, which can lead to inadvertent errors.
Best practice
Avoid using type inference for function return types.
Interested readers may wonder why using auto when initializing variables is okay, but not recommended for function return types. A good rule of thumb is that auto is okay to use when defining a variable, because the object the variable is inferring a type from is visible on the right side of the statement. However, with functions, that is not the case -- there’s no context to help indicate what type the function returns. A user would actually have to dig into the function body itself to determine what type the function returned. It’s much less intuitive, and therefore more error prone.
Trailing return type syntax
The auto keyword can also be used to declare functions using a trailing return syntax, where the return type is specified after the rest of the function prototype.
Consider the following function declaration:
|
1 |
int add(int x, int y); |
Using auto, this could be equivalently written as:
|
1 |
auto add(int x, int y) -> int; |
In this case, auto does not perform type inference -- it is just part of the syntax to use a trailing return type.
Why would you want to use this?
One nice thing is that it makes all of your function names line up:
|
1 2 3 4 |
auto add(int x, int y) -> int; auto divide(double x, double y) -> double; auto printSomething() -> void; auto generateSubstring(const std::string &s, int start, int len) -> std::string; |
For now, we recommend the continued use of the traditional function return syntax. But we’ll see this trailing return type syntax crop up again in lesson 7.15 -- Introduction to lambdas (anonymous functions).
Type inference for function parameter types
Many new programmers try something like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#include <iostream> void addAndPrint(auto x, auto y) // only valid starting in C++20 { std::cout << x + y; } int main() { addAndPrint(2, 3); // int addAndPrint(4.5, 6.7); // double } |
Prior to C++20, this won’t work, because the compiler can’t infer types for function parameters x and y at compile time. Pre-C++20, if you’re looking to create generic functions that work with a variety of different types, you should be using function templates (covered in a later chapter), not type inference.
Starting in C++20, the auto keyword can be used as a shorthand way to create function templates, so the above code will compile and run. Note that this use of auto does not perform type inference.
For advanced readers
Lambda expressions have supported auto parameters since C++14. We’ll cover lambda expressions in a future lesson.
As an aside...
If you’re wondering what the auto keyword did pre-C++11, it was used to explicitly specify that a variable should have automatic duration:
|
1 2 3 4 5 6 |
int main() { auto int foo(5); // explicitly specify that foo should have automatic duration return 0; } |
However, since all local variables in modern C++ default to automatic duration unless otherwise specified, the auto keyword was superfluous, and thus obsolete.
 6.15 -- Implicit type conversion (coercion) |
 Index |
 6.13 -- Typedefs and type aliases |
So basically, c++ keyword auto has the same purpose as c#, javaScripts etc keyword var?
Yes
Hello!
1) Is there any performance-wise drawback for using "auto"?
2) You mentioned that the compiler might guess your variable type wrong (not using these words though, and correct me if I'm wrong). Does this mean that duck-typed programming languages like Python suffer from this drawback by design?
Thanks
1) No.
2) The compiler won't guess it wrong. However, if you use auto as a function return value, the caller of the function might get it wrong. This could cause any number of problems to manifest, possibly resulting in incorrect or undefined behavior.
auto is evil !
why ?
auto value = doSomethingWith(int x);
The compiler may see the type of value, BUT YOU DO NOT !!!
what type is value here ?, anyone ?
Auto isn't evil, it just needs to be used appropriately.
Your example would be a misuse, as it gives no context as to what type of return value to expect. But something like:
is fine -- it's clear we're returning some kind of Dictionary object.
A good rule of thumb is: "Use auto when it's hard to write the type, but the type is obvious".
I've been using the auto keyword quite freely. But I can't figure out what the actual type is in this example:
I can't reproduce your error. Please post a minimal example that causes the error.
Not sure what you mean. Should I post a minimal compilable version?
Btw, when I hover over 'begin' in both MSVC AND VSCode, it says 'container<char>::iterator' and I'm very surprised this isn't correct.
It is `container<char>::iterator`. There's something else wrong in your code.
> Should I post a minimal compilable version?
"compilable" is going to be hard, because your code doesn't compile. Post a minimal version that causes your error and no other errors.
Hi,
Finally returned to this problem. As previously stated, @auto works, but when I attempt to do it 'manually', I get an error. Here's code showing the problem:
You have one "ring" in line 4 and another "ring" in line 44. Line 45 only sees the "ring" from line 44. Use different name styles for variables, functions and types.
I will NEVER make this mistake again :)
Thanks.
When will you start advance c++ topics. I really need it.
You can look at the front page of the site to see what topics are covered when.
Perhaps I'm a bit early, but I am really wondering if auto makes my life easier.
I do see the sense in Go where auto is not needed
I could see the sense if something like this were possible:
Well, I guess not... but maybe I am just getting ahead of things.
(BTW. Just to note... This is the 6th C++ tutorial I've seen, but the first one in which a simple "Hello World" example didn't give me compile errors, already, and this tutorial made me write the first C++ code that actually WORKS. I always felt silly that I've been coding for almost 35 years and I could never master C and C++, so thanks a lot). ;)
Snippet 1
* Line 1, 2, 4: Initialize your variables with brace initializers. You used copy initialization.
@auto comes in handy when you get to templates. Types can fill up entire lines
[auto calculateThis(int x, double d) -> std::string;] How it evauluates to std::string. Should'nt it be double?
Hi!
Without knowing what @calculateThis does, it could return anything. Judging by the function's name, you're right, it should most likely return an int or double.
The trailing return type syntax moves the return type from before the function name to after the function name.
"auto calculateThis(int x, double d) -> std::string" clearly returns a std::string (as the "-> std::string" part of the declaration indicates).
auto in this context doesn't perform type inference in this context, it just acts as a placeholder.
Yep, that's right. There's nothing wrong with the code. It's just that me, and apparently Gurdeep, don't see why a function called "calculateThis" would return a string.
Oh! I suppose that's true. I updated the function name and parameters to something that's more likely to be seen in the wild.
I am not in love with this "auto" keyword to be used for variables either, makes me kinda lazy not to even care about my variable type just like dynamically typed languages cant even use unsigned types, and I think it increases compilation time also
Wait until you get into nested template types. Then you'll change your mind. :)
Thanks...I am eager to
Hey Alex,
Although Type Inference could be applied to members of struct or class
we have to make them static and const, then we could initialize them.
I don't see any use for this.
Could you care to explain, what could be the uses for such an use of Type Inference ?
hi Alex
Am I doing something wrong or is ok to say that auto cant be used to define a variable in a .h file?
I am attempting to do this in visual studio 2017 which i am guessing uses vc2015. I dont what version of Cpp it uses.
great tutorials by the way
Hi Balqsmite!
auto can be used in header files just fine, without code I'm guessing you're not initializing the variable in which case there's no way for your compiler to know which data type it should be.
The article is very useful Alex. Keep it up!!
Precise and well written. Thank you for this tutorial!
Why did u write &x and &y and not x and y in function parameters?
My error. Those are reference parameters, which I haven't covered yet. I've updated the example to one that does not use reference parameters.
When you are so smart you accidently use smart things in easy tutorials
More to the point, it's hard to break habits and do things inefficiently because you haven't covered the optimal way to do it yet. :)
> This is called automatic type deduction.
Actually AFAIK it's simply called type inference - https://en.wikipedia.org/wiki/Type_inference
Thanks for the heads up. I've updated the lesson accordingly!
Why can I not do something like this?:
this does not compile.
But if it did, I could use a function like this instead of overloading functions.
Auto tells the compiler to infer the proper type -- because the compiler does the inferring, the type has to be inferable at compile-time. Your example doesn't work because x and y (and the thus the return type) can't be determined at compile time.
However, C++ does provide functionality to do what you want. In chapter 13 I talk about function templates, which are designed to do exactly what you're intending here.
(Note that this restriction may be lifted in future versions of C++)
auto keyword can easily be used by int, double, char etc.. but not used with string.
why? when used. it is written as PKc. what does it mean?
Auto works just fine with std::string (and char*), so not sure what you mean when you say it can't be used with string.
Can the auto keyword be used for function return type deduction when the return type is void(or as part of the trailing return type syntax)?
Yes. I've updated to lesson to explicitly indicate so.
In the first paragraph, the wording needs to be updated to say that local variables are created upon definition(not when entering the block).
Hope I'm not getting annoying :)
Not annoying at all -- on the contrary, you're making the lessons better for all the future readers, and for that, I think you.
"While this may seem neat, we recommend that this syntax be avoided for functions that return a fixed type. The return type of a function is of great use in helping to document a function. When a specific type isn’t specified, the user may not know what is expected.
(Side note: Interested readers may wonder why using auto when initializing variables is okay, but not recommended for function return types. A good rule of thumb is that auto is okay to use within the boundaries of a statement, because the type being inferred often doesn’t matter, and if it does, the actual type information is generally at hand. However, across statement boundaries, it’s better for documentation and maintenance to make types explicit.)"
I don't understand few things in this excerpt:
1. what are fixed types
2. to document a function
3. in which case you think that the user needs to know to type
4. what can be referred as a boundary of statement
5. `the type being inferred often doesn’t matter, and if it does, the actual type information is generally at hand`- what you mean with this
Rather than answer all of these questions, I updated the wording of that section substantially. Have another read and see if it's clearer now. If not, let me know what's still confusing.
Would the use of automatic type deduction in C++ affect the performance? If auto keyword is used extensively in C++ then the compiler has to figure out the data type every time, which would degrade performance.
Correct me if I am wrong.
Great tutorials. Love them :)
No, the compiler already needs to know the type in order to do strong type checking (to give you an error if you try to do something nonsensical). Auto is really just a convenience for the programmer.
Thanks for the good work. In my opinion, this is the best programming tutorial that I have used. Thanks again.
"auto d = 5.0; // 5.0 is a double literal, so d will be type double"
It's a double literal because there is no "f" or "l" at the end of the number?
Correct.
hey alex i am using codeblocks and this program is throwing error saying that k and l are not declared.
It sounds like your code::blocks isn't set to use C++11 functionality. See http://stackoverflow.com/questions/18174988/how-can-i-add-c11-support-to-codeblocks-compiler for a solution.
hello alex,
I used the auto keyword in a class as a public member on two variables in Qt creator, and the compiler flagged it as an error saying that: "a non-static data member cannot have a type that contains auto".
do you know why this may have occurred?
thanks
It looks like struct and class members can only be made auto if they are also static.
Yup Boyan is right. Remove "we will" from the following sentence:
"While using auto in place of fundamental data types only saves a few (if any) keystrokes, in future lessons we’ll we will see examples where the types get complex and lengthy."
Just highlighting the typo made in this section. :)
Just above the "Automatic type deduction for functions in C++14" headline, you've written "we’ll we will see "
I've got to say though...this is probably the best tutorial I've seen on ANYTHING, let alone C++! Thank you for the awesome work! :)
Typo fixed. Thanks for the compliment.