So, I´m checking this guy on Twitch http://www.twitch.tv/whilke, another game develorper using C++, and I notice he uses a lot of "auto" for variable declaration.
I ask he why so many, and the answer was:
"Why not to use auto?".
So, anyone here what are the pros and cons of using auto?
I ask he why so many, and the answer was:
"Why not to use auto?".
So, anyone here what are the pros and cons of using auto?
I can almost guarantee you that the answer for most people is "it's new and I've not learned it that way".
Well the usual arguments for are
* less to type for long typenames (especially templates)
* you don't repeat yourself that often
* if you change the type in one place you don't need to change it everywhere, since you didn't repeat it
* you can circumvent some implicit, potentially expensive conversions
contra are
* type is not always immediately clear to the reader without an IDE
* since no implicit conversion takes place you may get intermediate types that were never meant to be used (sometimes used in more complicated operator overloads)
* obviously doesn't work on pre-C++11 compilers and is not compatible with C
Well the usual arguments for are
* less to type for long typenames (especially templates)
* you don't repeat yourself that often
* if you change the type in one place you don't need to change it everywhere, since you didn't repeat it
* you can circumvent some implicit, potentially expensive conversions
contra are
* type is not always immediately clear to the reader without an IDE
* since no implicit conversion takes place you may get intermediate types that were never meant to be used (sometimes used in more complicated operator overloads)
* obviously doesn't work on pre-C++11 compilers and is not compatible with C
I thought "auto" was a easy way of doing templates and stuff not use everywhare in your code when you declare any variable.
If you don´t care the tipe of the variable you shouldn´t even have a key word for that.
If you don´t care the tipe of the variable you shouldn´t even have a key word for that.
The big problem I have with it is that you can't tell what type of variable it is. I had a problem with this in Javascript, like if there's something like var t=p.
what is the type for p? you would have to go around and look for it. It's really annoying. The good thing is that some people do something like auto p = new int() or something like that so we know what the variable type is and don't have to waste time looking for the type.
what is the type for p? you would have to go around and look for it. It's really annoying. The good thing is that some people do something like auto p = new int() or something like that so we know what the variable type is and don't have to waste time looking for the type.
Personally, I believe you should use auto whenever it makes sense, if the type information is already there, repeating it is just redundant, and I find auto does not hurt readability at all. That is to say, use auto when the type auto deduces is the type you wish to declare, as the type is already obvious from the rhs of the declaration.
Examples when I /don't/ use auto are (note: I program in D):
1. return type deduction in a function signature: unless there is a good reason for it I find this legitimately hurts readability
2. declaring a variable without initializing (which is done explicitly in D with = void, when default initialization is not wanted)
3. when declaring fixed size arrays, as D's auto always deduces arrays as dynamic.
That said, I do think it is personal preference to some degree.
auto answer = 42; is nice in my mind, because the type is expressed on the right hand side implicitely, I know at a glance that answer is an int, so typing int is redundant. This makes declarations with an initializer more uniform, but that is only a stylistic choice. Other people will argue that int answer = 42; is superior because it is one less character to type; they would only use auto when the type name is long. I don't like that personally because it is less consistent.
Examples when I /don't/ use auto are (note: I program in D):
1. return type deduction in a function signature: unless there is a good reason for it I find this legitimately hurts readability
2. declaring a variable without initializing (which is done explicitly in D with = void, when default initialization is not wanted)
3. when declaring fixed size arrays, as D's auto always deduces arrays as dynamic.
That said, I do think it is personal preference to some degree.
auto answer = 42; is nice in my mind, because the type is expressed on the right hand side implicitely, I know at a glance that answer is an int, so typing int is redundant. This makes declarations with an initializer more uniform, but that is only a stylistic choice. Other people will argue that int answer = 42; is superior because it is one less character to type; they would only use auto when the type name is long. I don't like that personally because it is less consistent.
You can find more detailed arguments about using auto here (slides 12 to 21): https://github.com/CppCon/CppCon2...%20-%20CppCon%202014.pdf?raw=true
( Warning, these slides may contain repeated mentions of "modern C++", "safe pointers" and other non-gamedev-friendly vocabulary and constructs, please make sure you are in a safe and calm environment before opening this file ;) )
( Warning, these slides may contain repeated mentions of "modern C++", "safe pointers" and other non-gamedev-friendly vocabulary and constructs, please make sure you are in a safe and calm environment before opening this file ;) )
d7samuraiglaze
In many cases you can tell the type by looking at the right-hand side, example:
How can you tell what the type is in that example?
Ok, maybe that wasn't a good example. Here's another:
1 | auto v = std::make_unique<Vec3>(); |
It's clear that v is an std::unique_ptr<Vec3> (at least for people who know about std::make_unique)
auto sure is convenient in the context of C++ (template madness, crazy long types with angle brackets and :: everywhere...), but I've already run into a few issues where in that zone of programming and then I run into an "auto". *BOOM*. What is that...? Search through the file/s to try to find out what that thing actually is.
Convenient at the time I originally typed it, very inconvenient for me later when I'm rewriting/modifying code. I've been shying away from its use for precisely this reason.
It does enable the use of lambda's though, which are unutterable types, so it necessitates auto...
Yeah, I try to avoid C++ features these days.
Convenient at the time I originally typed it, very inconvenient for me later when I'm rewriting/modifying code. I've been shying away from its use for precisely this reason.
It does enable the use of lambda's though, which are unutterable types, so it necessitates auto...
Yeah, I try to avoid C++ features these days.
DaleKim
It does enable the use of lambda's though, which are unutterable types, so it necessitates auto...
You can implicitly convert them to a std::function (it's not computationally free though, so if you can get away with it, the auto is better).
If anyone is wondering why the type is unutterable, lambdas in C++ are basically syntactic sugar for functors and the compiler needs to give them a type but the standards committee decided it would be best if the type was completely up to the compiler and the does not need to be known to the programmer (and should not clash with any user-defined name, well it technically doesn't need a name, just a way for the compiler to reference it)
Edited by Bigpet
on
d7samuraiglaze
In many cases you can tell the type by looking at the right-hand side, example:
How can you tell what the type is in that example?
it should be clear from the naming that this type will be whatever represents the concept of a "mesh." For example, a "Mesh" struct. I've never run into confusion over what a type is with auto in situations like this personally. Unless you are writing intentionally confusing code, it should be relatively obvious.
Edited by Neo Ar
on