auto — deduction of a type from an initializer

Consider


	auto x = 7;

Here x will have the type int because that’s the type of its initializer. In general, we can write


	auto x = expression;

and the type of x will be the type of the value computed from “expression”.

The use of auto to deduce the type of a variable from its initializer is obviously most useful when that type is either hard to know exactly or hard to write. Consider:


	template<class T> void printall(const vector<T>& v)
	{
		for (auto p = v.begin(); p!=v.end(); ++p)
			cout << *p << "\n";
	}

In C++98, we’d have to write


	template<class T> void printall(const vector<T>& v)
	{
		for (typename vector<T>::const_iterator p = v.begin(); p!=v.end(); ++p)
			cout << *p << "\n";
	}

When the type of a variable depends critically on template argument it can be really hard to write code without auto. For example:


	template<class T, class U> void multiply(const vector<T>& vt, const vector<U>& vu)
	{
		// ...
		auto tmp = vt[i]*vu[i];
		// ...
	}

The type of tmp should be what you get from multiplying a T by a U, but exactly what that is can be hard for the human reader to figure out, but of course the compiler knows once it has figured out what particular T and U it is dealing with.

Ref : http://www.stroustrup.com/C++11FAQ.html#auto

C++11 feature: trailing return types

In C++03, the return type of a function template cannot be generalized if the return type relies on those of the template arguments. Here is an example, mul(T a, T b) is a function template that calculates the product of a and b. Arguments a and b are of an arbitrary type T, which is not decided until the template instantiation. Thus, we cannot declare a return type for mul to generalize all the cases for a*b. If we must define such a function template, we have to introduce another template parameter as follows:

template<class Tclass U>

U mul(T a, T b){

return a*b;

}

We have some trouble to instantiate this function template because we have to explicitly provide type U in the template instantiation. Can we use feature decltype to let the compiler deduce the result type automatically? See the following example:

template<class T>

decltype(a*b) mul(T a, T b){

return a*b;

}

This program lets the compiler deduce the return type of function template mul. Unfortunately, it doesn’t work. The compiler is parsing codes from left to right, so it will issue an error message to indicate that variables a and b are used before their declarations.

To solve this problem, C++11 introduced a feature called trailing return types. Using this feature, the previous program can be rewritten as follows:

template<class T>

auto mul(T a, T b) -> decltype(a*b){

return a*b;

}

We specify the function return type after the declaration of parameter declarations. Composite symbol ->decltype(t1+t2) is called a trailing return type. The auto keyword is placed before the function identifier, which is the placeholder of the return type specifier. When a trailing return type is used, the placeholder return type must be auto. Meanwhile, the auto type specifier cannot be used in a function declaration without a trailing return type.

The biggest difference between ordinary functions and functions using trailing return types is whether to postpose the return types. See the following example:

auto max(int a, int b) -> int{}

Function max is using a trailing return type, which is equal to int max(int a, int b). This example shows a valid scenario of trailing return types, but it doesn’t reflect the benefits of this feature. We can fully enjoy the convenience of generic programming by using trailing return types. See the following example:

#include <iostream>

using namespace std;

template<typename T1, typename T2>

auto sum(T1 & t1, T2 & t2) -> decltype(t1 + t2){

return t1 + t2;

}

int main(){

auto i = 1;

auto j = 1.3;

auto k = sum(a,b);

cout << c << endl;

}

This program doesn’t contain any explicitly specified types. All the types are deduced by the compiler using auto type deductions and trailing return types, which saves a lot of programming efforts.

Reference : https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/introduction_to_the_c_11_feature_trailing_return_types?lang=en