How much is too much with C++11 auto keyword?
I think that one should use the auto
keyword whenever it's hard to say how to write the type at first sight, but the type of the right hand side of an expression is obvious. For example, using:
my_multi_type::nth_index<2>::type::key_type::composite_key_type::
key_extractor_tuple::tail_type::head_type::result_type
to get the composite key type in boost::multi_index
, even though you know that it is int
. You can't just write int
because it could be changed in the future. I would write auto
in this case.
So if the auto
keyword improves readability in a particular case then use it. You can write auto
when it is obvious to the reader what type auto
represents.
Here are some examples:
auto foo = std::make_shared<Foo>(); // obvious
auto foo = bla(); // unclear. don't know which type `foo` has
const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
// since max_size is unsigned
std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
// ok, since I know that `it` has an iterator type
// (don't really care which one in this context)
Confusion about auto keyword in C++
auto
is not a storage class. It used to be, before C++11. But it was completely useless, so the keyword was re-purposed to allow automatic type inference. So when you say:
auto int ret = foo();
You are basically declaring the object to have 2 types (or possibly the same type twice), and that is an error. And when you say:
auto ret = foo();
The type of ret
is determined by whatever the function foo
returns, which is int*
in this case.
auto keyword strange behavior in C++11
The auto
storage class specifier is not "useless and deprecated in C++11," it has been removed entirely. The auto
keyword is no longer a storage class specifier and cannot be used as one.
In C++11, auto
is a simple type specifier.
The new keyword auto; When should it be used to declare a variable type?
I think when the type is very well-known amongst the co-programmers who work (or would work) in your project, then auto
can be used, such as in the following code:
//good : auto increases readability here
for(auto it = v.begin(); it != v.end(); ++it) //v is some [std] container
{
//..
}
Or, more generally,
//good : auto increases readability here
for(auto it = std::begin(v); it != std::end(v); ++it)//v could be array as well
{
//..
}
But when the type is not very well-known and infrequently used , then I think auto
seems to reduce readability, such as here:
//bad : auto decreases readability here
auto obj = ProcessData(someVariables);
While in the former case, the usage of auto
seems very good and doesn't reduce readability, and therefore, can be used extensively, but in the latter case, it reduces readabilty and hence shouldn't be used.
Another place where auto
can be used is when you use new
1 or make_*
functions , such as here:
//without auto. Not that good, looks cumbersome
SomeType<OtherType>::SomeOtherType * obj1 = new SomeType<OtherType>::SomeOtherType();
std::shared_ptr<XyzType> obj2 = std::make_shared<XyzType>(args...);
std::unique_ptr<XyzType> obj2 = std::make_unique<XyzType>(args...);
//With auto. good : auto increases readability here
auto obj1 = new SomeType<OtherType>::SomeOtherType();
auto obj2 = std::make_shared<XyzType>(args...);
auto obj3 = std::make_unique<XyzType>(args...);
Here it is very good, as it reduces the use of keyboard, without reducing the readability, as anyone can know the type of objects being created, just by looking at the code.
1. Avoid using new
and raw-pointers though.
Sometime, the type is so irrelevant that the knowledge of the type is not even needed, such as in expression template; in fact, practically it is impossible to write the type (correctly), in such cases auto
is a relief for programmers. I've written expression template library which can be used as:
foam::composition::expression<int> x;
auto s = x * x; //square
auto c = x * x * x; //cube
for(int i = 0; i < 5 ; i++ )
std::cout << s(i) << ", " << c(i) << std::endl;
Output:
0, 0
1, 1
4, 8
9, 27
16, 64
Now compare the above code with the following equivalent code which doesn't use auto
:
foam::composition::expression<int> x;
//scroll horizontally to see the complete type!!
foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<int>, foam::composition::expression<int>, foam::operators::multiply>> s = x * x; //square
foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<int>, foam::composition::expression<int>, foam::operators::multiply> >, foam::composition::expression<int>, foam::operators::multiply>> c = x * x * x; //cube
for(int i = 0; i < 5 ; i++ )
std::cout << s(i) << ", " << c(i) << std::endl;
As you can see, in such cases auto
makes your life exponentially easier. The expressions used above are very simple; think about the type of some more complex expressions:
auto a = x * x - 4 * x + 4;
auto b = x * (x + 10) / ( x * x+ 12 );
auto c = (x ^ 4 + x ^ 3 + x ^ 2 + x + 100 ) / ( x ^ 2 + 10 );
The type of such expressions would be even more huge and ugly, but thanks to auto
, we now can let the compiler infer the type of the expressions.
So the bottomline is: the keyword auto
might increase or decrease clarity and readability of your code, depending on the context. If the context makes it clear what type it is, or at least how it should be used (in case of standard container iterator) or the knowledge of the actual type is not even needed (such as in expression templates), then auto
should be used, and if the context doesn't make it clear and isn't very common (such as the second case above), then it should better be avoided.
C++ auto keyword. Why is it magic?
auto
was a keyword that C++ "inherited" from C that had been there nearly forever, but virtually never used because there were only two possible conditions: either it wasn't allowed, or else it was assumed by default.
The use of auto
to mean a deduced type was new with C++11.
At the same time, auto x = initializer
deduces the type of x
from the type of initializer
the same way as template type deduction works for function templates. Consider a function template like this:
template<class T>
int whatever(T t) {
// point A
};
At point A, a type has been assigned to T
based on the value passed for the parameter to whatever
. When you do auto x = initializer;
, the same type deduction is used to determine the type for x
from the type of initializer
that's used to initialize it.
This means that most of the type deduction mechanics a compiler needs to implement auto
were already present and used for templates on any compiler that even sort of attempted to implement C++98/03. As such, adding support for auto
was apparently fairly easy for essentially all the compiler teams--it was added quite quickly, and there seem to have been few bugs related to it either.
When this answer was originally written (in 2011, before the ink was dry on the C++ 11 standard) auto
was already quite portable. Nowadays, it's thoroughly portable among all the mainstream compilers. The only obvious reasons to avoid it would be if you need to write code that's compatible with a C compiler, or you have a specific need to target some niche compiler that you know doesn't support it (e.g., a few people still write code for MS-DOS using compilers from Borland, Watcom, etc., that haven't seen significant upgrades in decades). If you're using a reasonably current version of any of the mainstream compilers, there's no reason to avoid it at all though.
More recent revisions of the standard have added a few new places that auto
can be used. Starting with C++14, you can use auto
for the type of a parameter to a lambda:
[](auto s) { return s + 1; }
This does essentially the same thing as the example above--even though it doesn't explicitly use template
syntax, this is basically a template that deduces the type of the parameter, and instantiates the template over that type.
That was convenient and useful enough that in C++20, the same capability was added for normal functions, not just lambdas.
But, just as before all of this really comes down to using the same basic type deduction mechanism as we've had for function templates since C++98. auto
allows that to be used in more places, and more conveniently, but the underlying heavy lifting remains the same.
Does auto in C++ 11 make compile time longer?
auto
is one character longer than int
, so the lexer definitely has to do more work.
On the other hand, the compiler no longer has to check that the user provided an appropriate type, so my best guess is that auto
will be slightly faster.
In the end, you should probably not decide between type inference and explicit typing based on performance considerations. Intent and clarity should be the deciding factors.
How to use auto keyword in argument list in C++ 11?
void get_index(auto s_arra[], auto elem) {
//...
}
Would be valid only in C++20 (gcc error message is misleading)
previously, you use template the verbose way
template <typename T1, typename T2>
void get_index(T1 s_arra[], T2 elem) {
//...
}
and probably they use same type, so
template <typename T>
void get_index(T s_arra[], T elem) {
//...
}
Related Topics
Copy a File in a Sane, Safe and Efficient Way
Is #Pragma Once a Safe Include Guard
Why Does Modulus Division (%) Only Work With Integers
Multi-Character Constant Warnings
What Is the Correct Way of Using C++11'S Range-Based For
Difference Between an Int and a Long in C++
Why Cast Unused Return Values to Void
Are There Any Valid Use Cases to Use New and Delete, Raw Pointers or C-Style Arrays With Modern C++
How to Call C++ Function from C
How to Access Private Members from Outside the Class Without Using Friends
C99 Stdint.H Header and Ms Visual Studio
Why Does C++ Disallow Anonymous Structs