Auto and var types do have a type. The compiler will figure out what that is.
You might think this is just a shortcut and it sometimes helps cut down on the typing. But there are other benefits.
Let’s say you have a method that’s declared to return an int. And you want to create a local int variable to hold the result of calling this method. You could start out by declaring an int variable, giving it a name, and initializing it with the return value from calling the method. But what if you declared a local string variable and tried to initialize it with the same result of calling the method?
The compiler will give you an error. It knows the types int and string aren’t compatible. Now, if the compiler knows when there’s a mismatch, then it’s not very hard to imagine that the compiler could just figure out the type of the local variable itself. You don’t have to tell the compiler what type the variable should be.
In this case, the auto variable really is an int. The compiler is able to figure out the type because of how it gets initialized. You can’t just declare an auto variable and leave it uninitialized. You also can’t declare an auto variable and expect it to be some other type that doesn’t match.
This feature may not seem very remarkable yet. That’s just because the examples have been simple. The benefits of auto tend to increase as the difficulty of determining the type needed also increases. What if instead of a simple int return type from a method, that method is passed a collection as one of its parameters. And inside the method, you want to iterate through the items in that collection. You’ll need to declare the proper iterator type and assign that iterator the value you get from calling begin. This is just a more complicated return type than the simple example method that returned an int. But the same principle applies. This time, it really does save you some typing.
What you need to remember is that code changes. All the time. Especially during initial development. By using auto, you actually help isolate your code from changes. Let’s say that collection starts out as a vector of ints and later needs to change to a map of ints and some custom class. If you coded the iterator type explicitly needed to work with a vector of ints, then it’s going to have to change when the collection type changes. But if you took the easy way and used auto, then guess what? It can remain auto with the new collection. Sure, some of the code might have to change. After all, going from a vector to a map is a big change. But why not let the compiler do at least some of the work for you?
Listen to the episode for some more benefits of using auto or var to declare your variables. Or you can also read the full transcript below.
Transcript
You might think this is just a shortcut and it sometimes helps cut down on the typing. But there are other benefits.
Before I get to that though, how does auto or var work? It’s the same concept just that some languages call this auto and some call it var. And some probably have other names. I’ll call it auto here so I don’t have to keep referring to both names.
Let’s say you have a method that’s declared to return an int. And you want to create a local int variable to hold the result of calling this method. You could start out by declaring an int variable, giving it a name, and initializing it with the return value from calling the method. But what if you declared a local string variable and tried to initialize it with the same result of calling the method?
The compiler will give you an error. It knows the types int and string aren’t compatible. Now, if the compiler knows when there’s a mismatch, then it’s not very hard to imagine that the compiler could just figure out the type of the local variable itself. You don’t have to tell the compiler what type the variable should be.
In this case, the auto variable really is an int. The compiler is able to figure out the type because of how it gets initialized. You can’t just declare an auto variable and leave it uninitialized. You also can’t declare an auto variable and expect it to be some other type that doesn’t match. You can do both of these things with a normal full type specification. If you want to declare an int variable and leave it’s initial value unspecified, you can. And if you want to declare a double variable and assign it the return value of the method that returns an int, you can do that too. But if you declare an auto variable and assign it the int return value from the method, then it’s going to be an int type because that’s what matches.
This feature may not seem very remarkable yet. That’s just because the examples have been simple. The benefits of auto tend to increase as the difficulty of determining the type needed also increases. What if instead of a simple int return type from a method, that method is passed a collection as one of its parameters. And inside the method, you want to iterate through the items in that collection. You’ll need to declare the proper iterator type and assign that iterator the value you get from calling begin. This is just a more complicated return type than the simple example method that returned an int. But the same principle applies. This time, it really does save you some typing.
There’s more benefits you get from using auto and I’ll explain those right after this message from our sponsor.
Maybe you still aren’t convinced of the benefit of letting the compiler figure out the type for you. Maybe you feel like a more hardcore programmer because you take the time to specify exactly the type of the iterator needed. None of this easy stuff for you. Well, if that describes how you feel, then let me ask you what flavor of medicine do you buy? Do you go for the easy grape flavored medicine or the hardcore fish fat medicine? It is possible to get more benefits from easier solutions. And auto is just like grape medicine.
What you need to remember is that code changes. All the time. Especially during initial development. By using auto, you actually help isolate your code from changes. Let’s say that collection starts out as a vector of ints and later needs to change to a map of ints and some custom class. If you coded the iterator type explicitly needed to work with a vector of ints, then it’s going to have to change when the collection type changes. But if you took the easy way and used auto, then guess what? It can remain auto with the new collection. Sure, some of the code might have to change. After all, going from a vector to a map is a big change. But why not let the compiler do at least some of the work for you?
Listen to episodes 39 through 46 for more information about collection types and iterators.
So far, I’ve explained how auto can improve your code or save some typing. But it can actually be required for anonymous types such as a lambda where you don’t have a declared type name to use. For these cases, letting the compiler determine the type is the only way.
I’ll explain a couple more short concepts for today. These are specific to C++ because they deal with const and references. Both of these topics are very different in C++ and C#.
Okay, what do you do if your method returns an int but you actually want a const int local variable? If you just use auto, then you’re going to get an int because that’s what matches. The solution is simple. When you declare your local variable, declare it to be of type const auto. That’ll cause the compiler to figure out the int part and still let you tack on the const part. And it also doesn’t care if the source type is const or not. Your auto variable will only be const if you explicitly declare it to be const.
And finally, what happens if you declare a local auto variable and assign it a reference to an int? Do you get another reference to the same int? You don’t. What happens is the compiler looks at the type of the reference when figuring out what type the auto will be. The compiler doesn’t care if the type comes from the original name of the variable or from a reference to that type. It just looks at the type. But what if you really do want a reference and still use auto? The answer is just as simple as if you really want a const auto. In this case, just declare an auto reference local variable and assign it your initializing value. Just like const, your auto variable will only be a reference itself if you explicitly declared it to be a reference.