What kind of problems for not forwarding universal reference?

Question

As far as I know, in C++11, universal reference should always be used with std::forward, but I am not sure of what kind of problem can occur if std::forward is not used.

template <T>
void f(T&& x);
{
    // What if x is used without std::forward<T>(x) ?
}

Could you provide some illustrations of problems that could occur in this situation ?

Chlorinate

Answer 1

There is no such rule to always use std::forward with universal references. On the contrary, it can be dangerous to use std::forward all over the place in functions with universal references. Take a look at the following example:

template <typename T>
auto make_pair(T&& t)
{
    return std::make_tuple(std::forward<T>(t), std::forward<T>(t)); // BAD
}

If you call this function with make_pair(std::string{"foobar"}), the result is counter-intuitive, because you move from the same object twice.

---

Update: Here is another example to show, that it really makes sense to use universal references without perfect forwarding:

template <typename Range, typename Action>
void foreach(Range&& range, Action&& action)
{
    using std::begin;
    using std::end;
    for (auto p = begin(range), q = end(range); p != q; ++p) {
        action(*p);
    }
}

• It's good that range is a universal reference, so that the caller can use foreach with a temporary container and an action, that's calls a non-const member function on the elements.
• It's good that action is a universal reference, so that the caller can pass a mutable lambda expression as action.
• And it would be wrong to use std::forward for range or for action.

Lodgment

Very good point but it doesn't clearly answer the question "what kind of problem can occur if std::forward is not used?" – Literacy

+1, but why would it be wrong to use std::forward for action? I just read this: Why use a perfectly forwarded value?, and it seems you may throw away an optimization opportunity if not preserving the r-valueness. – Swat

@Snps: In contrast to std::apply, the above code contains a loop. Depending on the type of Action, std::forward<Action>(action) can be the same as std::move(action). That means with std::forward you would potentially change the function object action in the first iteration and causing strange behaviour for all remaining iterations. – Lodgment

@Lodgment Duh, the loop (how could I miss that). Makes sense now, thanks for clearing that up! – Swat

The first example is pretty bad. If the purpose is to make_tuple(t, t), then T&& probably should not be used in the first place—const T& would be better. – Werbel

Answer 2

Let's say f is called like this:

f(someType{});

If the body of f performs some kind of operation on x

foo(x);

and there are two overloads for foo

void foo(someType const&);

void foo(someType&&);

without using std::forward, as x is an lvalue the following overload is called

void foo(someType const&);

which might cost you a potential optimization.

Using

foo(std::forward<T>(x));

makes sure the correct overload of foo is selected.

Aleris

Answer 3

Things with a name are lvalues. That means that in the function body, t is an lvalue. It doesn't matter if the universal reference ends up as an lvalue reference or as an rvalue reference. If it's named, it's an lvalue.

If you thus pass that argument along directly, you will be passing an lvalue.

In a situation where you want to just pass along an opaque argument to another function, you want to pass it exactly as-is. If it was an lvalue, you want to pass it as an lvalue; if it was an rvalue you want to pass an rvalue. As explained, passing it directly passes it as an lvalue always. forward does the magic needed to pass it as the right kind of value,

Code that always passes an lvalue will likely suffer from a performance perspective but I would say that you can ignore that when thinking about this particular issue. There is a more pressing concern for not always passing an lvalue: while copying some types may be expensive, some other types cannot be copied at all, like std::unique_ptr. For those types preserving rvalueness when forwarding is not a matter of performance but of getting your code to even compile.

Predict

Answer 4

You should not forward a variable more than once.

Shulins