When to use decltype and auto?

autoallows you to deduce the type from the value with which the variable starts:

auto i = 5;   // int
auto f = 4.5; // double

However, autoit is not capable of covering the entire range of possibilities...

Imagine that you have to program a template such that:

tipo1 func(objeto)
{ return objeto.otraFunc(); }

How do you program that template?

Version 1

auto func(auto objeto)
{
  return objeto.otraFunc();
}

Valid in C++17, not so in C++11

version 2

template<class T, class U>
T func(U objeto)
{ return objeto.otraFunc(); }

Compatible with all versions but a bit cumbersome to use, since although the type Ucan be deduced automatically, the type Twill have to be indicated explicitly:

struct POO
{
  int otraFunc()
  { return 5; }
};

POO MiObjeto;
std::cout << func<int>(MiObjeto);

version 2.1

In order to deduce the two values, we create an intermediate structure as traits :

struct POO
{
  int otraFunc()
  { return 5; }
};

// Implementación por defecto = no valida
template<class T>
struct traits;

template<>
struct traits<POO>
{
  typedef int returnType;
};

template<class T>
typename traits<T>::returnType func(T objeto)
{ return objeto.otraFunc(); }


int main()
{
  POO MiObjeto;
  std::cout << func(MiObjeto);
}

Although it is easy to understand that this solution begins to be quite cumbersome.

version 3

... or we can also usedecltype

struct POO
{
  int otraFunc()
  { return 5; }
};

template<class T>
decltype(T().otraFunc()) func(T objeto)
{ return objeto.otraFunc(); }

    int main()
{
  POO MiObjeto;
  std::cout << func(MiObjeto);
}

In this case, it decltypeevaluates the expression T().otraFunc()which is nothing more than:

• T(): Simulates the creation of a new object of typeT
• T().otraFunc()simulates the call and keeps the return type of the function otraFuncfor the typeT

It could happen that the default constructor is Tnot available for a given type... in which case the above expression could not be evaluated... We can get a more generic version using pointers:

template<class T>
decltype(((T*)nullptr)->otraFunc()) func(T objeto)
{ return objeto.otraFunc(); }

As decltype it does not execute code but simply evaluates it, there is no risk of memory leaks or calls on invalid objects... of course we cannot use new...

By the way, there are people who prefer this other totally valid nomenclature in C++11

template<class T>
auto func(T objeto) -> decltype(((T*)nullptr)->otraFunc())
{ return objeto.otraFunc(); }

Of course decltypeit can also be used to evaluate simpler expressions:

decltype(5) var = 4; // decltype(5) == int
std::cout << var;    // imprime 4

float foo();
decltype(foo()) var2 = 4.5// float

decltype(var2) var3 = 3; // float

EDIT

Another way to use decltype, in combination with declval. So we don't have to worry about how the object should be created T:

template<class T>
auto func(T objeto) -> decltype(std::declval<T&>().otraFunc())
{ return objeto.otraFunc(); }

When is it more convenient to use decltypeenvelope autoand vice versa?

decltypeand autothey are not interchangeable or equivalent, their use, behavior and purpose is different.

autois a declarator that infers types in places where a declaration can be made with initialization:

• If the initializer is a literal, it will deduce the (non-constant) type of the literal.
• If the initializer is a reference, it will ignore the reference.
• If the initializer is qualified with constor volatile, these qualifiers will be ignored if applied on the object (first level qualifiers).
• If the initializer is an expression, it will deduce the (non-constant) type resulting from evaluating the expression (taking into account the previous points).
• If the initializer is a function, it will deduce the return type of the function (keeping the points above in mind).

decltype(...)is a declarator that copies the type of something already existing:

• If there is a literal between its parentheses, it will deduce the type (not constant) of it.
• If there is an expression or a function between its parentheses, it will deduce the type resulting from evaluating said expression (without actually evaluating it) or function (without making the call).
• If there is an expression in parentheses between its parentheses, it will treat it as Left Side Value and deduce reference.

As for when to use them, like any tool: When necessary.

When is it necessary?

There are things that cannot be programmed without the help of autoand decltype; They are usually things that are impossible (or difficult) for the programmer to know but trivial for the compiler, such as operations between unknown types:

template <typename I, typename D>
auto suma(I i, D d) -> decltype(i + d)
{
    return i + d;
}

In the context of the template function sumait is impossible for the programmer to know the return type of the function, we don't know what type it is Iand what type it is Dand we won't know until the moment we instantiate the template, but we can't change the template in ! compile time!

Luckily, the compiler has that information that the programmer lacks and knows, at the moment of instantiating the template, what types they are Iand D, in this context auto, it tells the compiler: " I don't know what type of return the function has but it will be deduced later " while decltypeit tells you " Deduce the type of the expression i + dand assign it to the return of the functionsuma ".

So that:

• suma(1, 2.f)has as return type float.
• suma<std::string>("patatas", " fritas!")has as return type std::string.

For the same reason that leads us to ignore the return type of this function, we cannot create a variable to capture its value:

template <typename I, typename D>
auto suma(I i, D d) -> decltype(i + d)
{
    return i + d;
}

template <typename I, typename D, typename ... T>
auto super_suma(I i, D d, T ... tipos)
{
    ???? sub_suma = suma(i, d);
 // ~~~~ <--- que tipo debo usar aqui?

    if constexpr (sizeof...(tipos) >= 2)
        return sub_suma + super_suma(tipos ...);
    if constexpr (sizeof...(tipos) == 1)
        return sub_suma + std::get<0>(std::make_tuple(tipos ...));
    if constexpr (sizeof...(tipos) == 0)
        return sub_suma;
}

sub_sumaIn the function variable super_sumareturns static type deduction ( auto) to the rescue:

template <typename I, typename D, typename ... T>
auto super_suma(I i, D d, T ... tipos)
{
    auto sub_suma = suma(i, d);
 // ~~~~ <--- Deja que el compilador lo deduzca por ti!

    if constexpr (sizeof...(tipos) >= 2)
        return sub_suma + super_suma(tipos ...);
    if constexpr (sizeof...(tipos) == 1)
        return sub_suma + std::get<0>(std::make_tuple(tipos ...));
    if constexpr (sizeof...(tipos) == 0)
        return sub_suma;
}

Note that super_sumait does not use -> decltypeafter the definition; this is a feature of C++14 known as Function Return Type Deduction .

limitations of autoanddecltype

The way it works automakes it impossible to derive references unless you do it explicitly:

const std::string TEXTO_CONSTANTE("Hola mundo!");

auto f1() { return TEXTO_CONSTANTE; } // auto deduce std::string
auto &f2() { return TEXTO_CONSTANTE; } // auto deduce const std::string &

If we wanted to implicitly deduce the return as const(which is the actual type) we should rely on decltype:

const std::string TEXTO_CONSTANTE("Hola mundo!");
// auto deduce const std::string
auto f1() -> decltype(TEXTO_CONSTANTE) { return TEXTO_CONSTANTE; }

As of C++14 it is possible to combine decltypeand automore directly to deduce the actual return type of a function using decltype(auto):

const std::string TEXTO_CONSTANTE("Hola mundo!");
// Estilo C++11 auto deduce const std::string
auto f1() -> decltype(TEXTO_CONSTANTE) { return TEXTO_CONSTANTE; }
// Estilo C++14 auto deduce const std::string
decltype(auto) f2() { return TEXTO_CONSTANTE; }

Sometimes it is not necessary, but it is useful.

The declarator autoallows us to ignore the type in places where we normally need to duplicate it, for example this:

auto monstruosidad = new std::map<std::pair<std::size_t, std::uint64_t>, std::u32string>();

It's more comfortable to read than this:

std::map<std::pair<std::size_t, std::uint64_t>, std::u32string> *monstruosidad = new std::map<std::pair<std::size_t, std::uint64_t>, std::u32string>;

It also allows us to completely ignore the type so this:

auto insercion = monstruosidad->insert({{0, 0}, u32"Patata frita!"});

It's more comfortable to read than this:

std::pair<std::map<std::pair<std::size_t, std::uint64_t>, std::u32string>::iterator, bool> insercion = monstruosidad->insert({{0, 0}, u32"Patata frita!"});

This type of use autohas given rise to a trend called " Almost Alwaysauto " (in English " Almost Always Auto " or AAA, a term coined by Herb Sutter ) that advises us to use it autoin almost all situations. The article dedicated to AAA is excellent ¹ , I will only translate the parts that I consider most relevant:

laziness and commitment

Laziness first: "typing autoto declare a variable is mostly typing less" is a common concern. However, this is a misunderstanding of the purpose of auto. [...], the main reasons for declaring variables using autoare correctness, performance, maintainability, robustness, and yes, convenience, but it's last on the list.

Second, commit: "But in some cases I want to commit to a specific type, not automatically deduce it, so I can't use auto." It's true that sometimes you need to commit to a specific type, but even then you can use auto. [...], not only can you write declarations like auto x = tipo{ inicializador };(instead of tipo x{inicializador};) to commit to a specific type, but there are also good reasons to do so, like for example autoit means you can't forget to initialize the variable.

(I)readability

The most common […] of the arguments is about readability: “My code becomes unreadable very quickly when I don't know the exact type of my variables unless I scan the return of the function or expression, so I can't always use auto.” There is truth to this, including the possibility of being able to search for specific types using untyped syntax auto x = expresion;[...] so this might seem like a good argument. And it is true that any feature can be overused. However, I think this argument is weaker than it seems for four reasons, two minor and two major.

The two minor counterarguments are:

• The “can't use auto” part is not true, because as we just saw before you can make the type explicit and still use auto, with good benefits.
• This argument doesn't apply if you're using an EDI , because you can always know the exact type, for example by hovering over the variable. Granted, this is lost when you leave EDI behind, for example when printing the code.

The two major counterarguments are:

• It shows a preference for programming implementations, not interfaces. Overcommitting to explicit types makes code less generic and more interdependent, and therefore more brittle and limited. [...]
• We (meaning you) already ignore specific types continuously…

¹ Although I do not fully agree with it.