The document discusses universal references and perfect forwarding in C++, focusing on solutions provided in C++11. It outlines the challenges of perfect forwarding prior to C++11 and explains how reference-collapsing rules and universal references simplify the process. It also covers the use of std::forward for preserving value categories and type qualifications during argument forwarding.

1. Andrey Upadyshev
Hot C++:
Universal References &
Perfect Forwarding
Licensed under a CC BY-SA 4.0 License. Version of 2017.11.16
1

2. Imagine a simple factory:
template<typename T, typename ???>
shared_ptr<T> makeShared(??? arg)
{
return shared_ptr<T>(new T(arg));
}
❖ The intent here is to pass the argument arg from the factory
function to T's constructor.
❖ Ideally, everything should behave just as if the factory function
weren't there and the constructor were called directly in the
client code i.e. a perfect forwarding.
Perfect Forwarding: The Problem
2

3. C++98 Solution
First approach is to take arg by const ref:
template<typename T, typename Arg>
shared_ptr<T> makeShared(const Arg& arg) {
return shared_ptr<T>(new T(arg));
}
std::string readFile();
makeShared<Foo>(readFile());
makeShared<Bar>(42);
Connection conn;
makeShared<Client>(conn);
// Compilation error: non-const lvalue ref passed
Overload for non-const ref should be added:
template<typename T, typename Arg>
shared_ptr<T> makeShared(Arg& arg) {
return shared_ptr<T>(new T(arg));
}
3

4. C++98 Solution
template<typename T, typename Arg>
shared_ptr<T> makeShared(const Arg& arg);
template<typename T, typename Arg>
shared_ptr<T> makeShared(Arg& arg);
Drawbacks:
❖ 2 overloads for one argument, 2^N overloads for N
arguments.
❖ Move semantics blocked in C++11.
- No more overloads, please!
4

5. Perfect Forwarding
Good news for everybody:
C++11 finally got a perfect solution!
But wait a bit…
5

6. Reference-Collapsing Rules
C++11 got new reference-collapsing rules in template instantiation context:
template<class T>
struct Collapse {
typedef T&& RvRef;
typedef T& LvRef;
}; typename Collapse<X&>::RvRef
• An rvalue reference to an rvalue reference becomes (collapses into) an
rvalue reference:
Collapse<X&&>::RvRef (X&& &&) → X&&
• Any other reference to reference (i.e., all combinations involving an
lvalue reference) collapses into an lvalue reference:
Collapse<X&&>::LvRef (X&& &) → X&
Collapse<X&>::RvRef (X& &&) → X&
Collapse<X&>::LvRef (X& &) → X&
❖ Reference-collapsing preserves cv-qualifiers of original type.
❖ It is still impossible to explicitly declare reference to reference.
6

7. Template Argument Deduction Rule
C++11 got special template argument deduction rule for
function templates:
template<typename T>
void foo(T&& t);
• When called with lvalue of type X then
T resolves to X& → argument type collapses into X&
• When called with rvalue of type X then
T resolves to X → argument type becomes X&&
7

8. Universal References
If a variable or parameter is declared to have type T&& for some
deduced type T, that variable or parameter is a universal reference.
— Scott Meyers, Universal References in C++11
template<typename T>
void foo(T&& t); // t is a universal reference
Of course, the name of typename does not matter,
it can be any type&&.
They are also known as forwarding references.
8

9. Universal References: Examples
template<typename Arg> // [1.1]
void foo(Arg&& arg);
arg is universal reference
void bar(Bar&& op); // [1.2]
std::string&& s = …; // [1.3]
Fully specified type ⇒ no type deduction, op and s are rvalue references
template<typename Arg> // [1.4]
void foo(const Arg&& arg);
Should be exactly type&& were type is deduced ⇒ arg is const rvalue
reference
template<typename Arg> // [1.5]
void foo(Arg& arg);
Should be type&& ⇒ arg is lvalue reference
9

10. Universal References: Examples
template<typename T>
class Vector {
Vector(Vector&& rhs); // [2.1]
…
void push_back(T&& t); // [2.2]
};
Fully specified type (When function is called the template is already
instantiated so Vector and T are “fixed”) ⇒ no type deduction, rhs and t
are rvalue references
template<typename T>
class Vector {
template<typename U> // [2.3]
Vector(U&& rhs);
…
};
rhs is universal reference
10

11. Universal References: Examples
template<typename T> // [3.1]
void print(std::vector<T>&& arg);
Should be exactly type&& were type is deduced ⇒ arg is rvalue
reference
template<typename... Args> // [3.2]
void foo(Args&&... args);
Parameter pack of universal references
auto&& i = …; // [3.3]
It is exactly type&& where type is deduced ⇒ i is universal reference
[](auto&& arg) {…}; // [3.4] C++14 lambda
It is exactly type&& where type is deduced ⇒ arg is universal
reference
11

12. std::forward
template<typename T>
void foo(T&& t) {
bar(std::forward<T>(t)));
}
❖ Forwards the argument to another function with preserving the
type, cv-qualifiers and value category (lvalue/rvalue).
❖ Somehow similar to std::move but should be applied only to
universal references
❖ std::forward is a conditional cast to rvalue (while std::move is
an unconditional one):
❖ Rvalue if applied to rvalue reference
❖ Lvalue if applied to lvalue reference
❖ Both do nothing at runtime
12

13. Perfect Forwarding: Solved!
Universal references and std::forward are a key:
template<typename T, typename Arg>
shared_ptr<T> makeShared(Arg&& arg)
{
return shared_ptr<T>(
new T(std::forward<Arg>(arg)));
}
❖ No overloads needed
❖ Forwarded arguments are exactly the same that was passed by
the caller.
❖ No copies or moves performed
13

14. Plays Nice With Variadic Templates
Perfectly forwards any number of arguments:
template<typename T, typename... Args>
shared_ptr<T> makeShared(Args&&... args)
{
return shared_ptr<T>(
new T(std::forward<Args>(args)...));
}
14

15. 15

16. Don’t Confuse std::move With std::forward
❖ std::move is used to unconditionally cast rvalue reference (or something
need to be forced) to rvalue.
template<typename T, typename Arg>
shared_ptr<T> makeShared(Arg&& arg)
{
return shared_ptr<T>(
new T(std::move(arg))); // What is wrong?
}
Using std::move with universal reference may lead to unexpected
move from lvalue.
❖ std::forward is used to forward universal reference, i.e. to conditionally
cast one to rvalue. Using it with rvalue reference is excessively uncommon
and so confusing.
16

17. URefs And std::forward Go Together
A universal reference is [almost] always used in
combination with std::forward. If you see former
without latter or vice versa, look for error!
Remember its second name a forwarding reference.
17
template<typename T>
void logAndBar(T&& t) {
std::cout << t << ‘n’;
bar(std::forward<T>(t)));
}
template<typename T>
Foo makeFoo(T&& t) {
return std::forward<T>(t);
}
template<class T>
struct Wrapper {
…
template<class U>
Wrapper(int id, U&& v)
: m_id(id)
, m_val(std::forward<U>(v))
{}
};

18. Use URefs And std::forward Carefully
❖ template<class T>
void foo(T&& t) {
Bar b(std::forward<T>(t));
std::cout << t.value(); // What is wrong?
…
}
Do not use forwarded-away objects because they may be in moved-
from state.
❖ Remember that std::forward may act as std::move. Check
previous presentation for std::move and rvalue related concerns.
❖ Remember that universal reference may be either rvalue reference
or lvalue reference. Write code accordingly.
18

19. Avoid Overloading on URefs
Imagine that we want to differently process rvalues (first overload)
and lvalues (second one):
template<typename T>
void foo(T&& t) {… std::move(t); …} // [1] rvalues
template<typename T>
void foo(T const& t) {…} // [2] lvalues
std::string s = “wow”;
foo(s);
WTF, overload [1] is called! Only const lvalues go to [2], all the rest
including non-const lvalues go to [1] because it takes universal
reference ⇒ accepts everything ⇒ a better match for everything
except const lvalue ref.
19

20. Avoid Overloading on URefs
Imagine that we want to have overload for integers:
template<typename T>
void foo(T&& t) {…} // [1] general case
void foo(long t) {…} // [2] integers
short s = 42;
foo(s);
WTF, overload [1] is called! Only longs go to [2], all the rest
including integers that need to be promoted to long integer go to
[1] because it takes universal reference ⇒ accepts everything ⇒
a better match for everything except a long integer.
20

21. Avoid Overloading on URefs
❖ Problem’s root cause is that universal reference parameter is too
“greedy” (by purpose) so become a better match more frequently
than expected.
❖ There are some solutions (Partially stolen from Meyers’ book):
❖ Abandon overloading by using different function names or
different number of parameters.
❖ Pass by const reference instead of universal reference.
❖ Pass params that are movable and copyable by value (and get
rid of template that uses universal references at all)
❖ Tag dispatch
❖ Constrain template that uses universal references
21

22. Avoid Overloading on URefs: Tag Dispatch
Using of compile time dispatching to implement overloading for
rvalues and lvalues:
template<typename T>
void foo(T&& t)
{
foo_impl(std::forward<T>(t),
std::is_lvalue_reference<T>());
}
template<typename T>
void foo_impl(T&& t, std::true_type) {…} // lvalues
template<typename T>
void foo_impl(T&& t, std::false_type) {…} // rvalues
22

23. URefs And Copy Constructor
Consider the simple wrapper:
template<typename T>
struct Wrapper {
T m_value;
…
template<typename U> // Single arg for simplicity
explicit Wrapper(U&& u)
: m_value(std::forward<U>(u)) {}
};
The purpose is to allow to construct Wrapper with whatever wrapped
type constructor accepts:
Wrapper<std::string> hello_world(“Hello, World!”);
23

24. URefs And Copy Constructor
template<typename T>
struct Wrapper {
T m_value;
…
template<typename U>
explicit Wrapper(U&& u)
: m_value(std::forward<U>(u)) {}
};
Looks OK?
Wrapper<std::string> w1(“Hello, World!”);
Wrapper<std::string> w2(w1); // Compilation error
For non-const lvalue reference the forwarding constructor is a better
match than [generated] copy constructor:
Wrapper(const Wrapper& rhs);
24

25. URefs And Copy Constructor
❖ Copy assignment operator has the same issue.
❖ Variadic forwarding constructor has the same issue.
template<typename... Ts>
struct tuple
{
template<typename... Us>
explicit tuple(Us&&... us);
// May be chosen instead of copy constructor
…
};
25

26. Constraining URef Template
Possible solution is to disable forwarding constructor for Wrapper and derived types:
template<typename T>
struct Wrapper {
T m_value;
…
template<
typename U,
typename = disable_if_same_or_derived_t<Wrapper, U>>
explicit Wrapper(U&& u)
: m_value(std::forward<U>(u)) {}
};
template<typename Base, typename Derived>
using disable_if_same_or_derived_t =
std::enable_if_t<
!std::is_base_of<
Base,
std::decay_t<Derived>
>::value
>; // C++14. A bit more verbose in C++11
26
std::enable_if
metafunction is a convenient
way to leverage SFINAE to
conditionally remove functions
from overload resolution based
on type traits.

27. Constraining URef Template 2
Another solution is to enable forwarding constructor only for types that may be used to construct T:
template<typename T>
struct Wrapper {
T m_value;
…
template<
typename U,
typename = std::enable_if_t<std::is_constructible<T, U&&>::value>>
explicit Wrapper(U&& u)
: m_value(std::forward<U>(u)) {}
}; // C++14. A bit more verbose in C++11
Easily extended to any number of arguments:
template<typename T>
struct Wrapper {
T m_value;
…
template<
typename... U,
typename = std::enable_if_t<std::is_constructible<T, U&&...>::value>>
explicit Wrapper(U&&... u)
: m_value(std::forward<U>(u)...) {}
}; // C++14. A bit more verbose in C++11
27

28. Constraining URef Template 3
Another solution is to disable forwarding constructor for types that otherwise
convertible to Wrapper. Which is true for Wrapper and derived types, for types that
got a dedicated constructor and types that implement a conversion to Wrapper.
template<class T>
struct Wrapper {
T m_value;
…
template<
typename U,
typename = std::enable_if_t<!std::is_convertible<U&&, Wrapper>::value>>
explicit Wrapper(U&& u);
explicit Wrapper(const Bar& bar); // A dedicated constructor for Bar
};
template<class T>
struct Foo {
operator Wrapper<T> () const; // Foo<T> provides a conversion to Wrapper<T>
};
Bar bar;
Foo<std::string> foo;
Wrapper<std::string> w1(bar), w2(foo); // ^ C++14. A bit more verbose in C++11
28

29. Perfect Forwarding Failures
❖ Braced initializer. Compiler can not deduce the type.
makeShared<std::vector<int>>({1, 2, 3});
User has to explicitly specify a type:
makeShared<std::vector<int>>(
std::initialized_list<int>({1, 2, 3}));
or
auto list = {1, 2, 3};
makeShared<std::vector<int>>(list);
❖ Overloaded function and function template names. A set of
functions that compiler can not choose a right one from.
You have to explicitly choose one function by casting the function
to a specific function pointer type.
29

30. Perfect Forwarding Failures
❖ 0 or NULL as null pointers. They are deduced to integral type instead of
pointer type. Use nullptr instead (not only in this case but always!).
❖ Declaration-only static const and constexpr data. Causes linker error.
struct Calendar {
static const int numberOfMonths = 12;
…
};
makeShared<int>(Calendar::numberOfMonths);
User has to add a definition for the data or pass a copy:
makeShared<int>(int(Calendar::numberOfMonths));
❖ Non-const bit-field. Non-const reference cannot bind to a bit-field. User has
to pass a copy:
makeShared<int>(int(var.bitField));
30

31. Useful Links
Thomas Becker, Perfect Forwarding: The Problem
http://thbecker.net/articles/rvalue_references/section_07.html
Scott Meyers, Universal References
http://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers
Eric Niebler, Universal References and the Copy Constructor
http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constructo/
(Im)perfect forwarding with variadic templates
stackoverflow.com/questions/13296461/imperfect-forwarding-with-variadic-
templates
C++11 Standard (final plus minor editorial changes)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
Scott Meyers, Effective Modern C++, (Item 1 & chapter 4)
31

32. Questions?
32