40

GCC 4.7 in C++11 mode is letting me define a function taking a lambda two different ways:

// by value
template<class FunctorT>
void foo(FunctorT f) { /* stuff */ }

And:

// by r-value reference
template<class FunctorT>
void foo(FunctorT&& f) { /* stuff */ }

But not:

// by reference
template<class FunctorT>
void foo(FunctorT& f) { /* stuff */ }

I know that I can un-template the functions and just take std::functions instead, but foo is small and inline and I'd like to give the compiler the best opportunity to inline the calls to f it makes inside. Out of the first two, which is preferable for performance if I specifically know I'm passing lambdas, and why isn't it allowed to pass lambdas to the last one?

Improve this question

3 Answers 3

Reset to default
34

FunctorT&& is a universal reference and can match anything, not only rvalues. It's the preferred way to pass things in C++11 templates, unless you absolutely need copies, since it allows you to employ perfect forwarding. Access the value through std::forward<FunctorT>(f), which will make f an rvalue again if it was before, or else will leave it as an lvalue. Read more here about the forwarding problem and std::forward and read here for a step-by-step guide on how std::forward really works. This is also an interesting read.

FunctorT& is just a simple lvalue reference, and you can't bind temporaries (the result of a lambda expression) to that.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

@Joseph: First, if you pass a temporary to your first function, the temporary will be moved into the parameter, not copied. It will only be copied in case you pass an lvalu. For the universal reference one, you will get neither copy nor move, since it's a reference that directly binds to the temporary (or lvalue or whatever is passed). Many times, you will have copy elision anyways, and won't see any copy / move at all (copy / move ctors with side effects can be elided and no side effects will occur, this is specifically allowed by the standard).
@JosephGarvin: On std::forward being moot if you don't pass it further: No, it's not. Image any functor (not specifically lambdas), with an operator() that is ref-qualified (see here) on both lvalues and rvalues, and the rvalue one does something different. If you don't use std::forward when passing in a temporary, you'll ever get the lvalue overload called. Basically, you do pass the functor - to its own member functions. ;)
So, if I'm understanding correctly, everywhere I have template code that takes template type parameters now I should take by &&, and every time I use the parameter where I don't explicitly want a copy I should be using std::forward<T>? That seems like a metric ton of extra boilerplate...
@Joseph: For full-blown genericity, yes, that is the path to code. Unless you explicitly want a read-only reference, then you can just go with T const& of course.
@JosephGarvin It's not wrong to consider that template<typename F> void foo(F f) { f(); } is the 'good enough' version of template<typename F> void foo(F&& f) { std::forward<F>(f)(); }. Except for what I would consider pathological case, you do not lose actual functionality -- you may do some unnecessary work, but you get to the same result either way.
|
5

When you create a lambda function you get a temporary object. You cannot bind a temporary to a non-const l-value references. Actually, you cannot directly create an l-value referencing a lambda function.

When you declare you function template using T&& the argument type for the function will be T const& if you pass a const object to the function, T& if you pass a non-const l-value object to it, and T if you pass it a temporary. That is, when passing a temporary the function declaration will take an r-value reference which can be passed without moving an object. When passing the argument explicitly by value, a temporary object is conceptually copied or moved although this copy or move is typically elided. If you only pass temporary objects to your functions, the first two declarations would do the same thing, although the first declaration could introduce a move or copy.

Improve this answer

4 Comments

@Nicol: The T in T&& will be a simple T (aka int), not T&& (aka int&&). Reference collapsing will only apply for lvalues, which would make the T in T&& yield T&.
Dietmar does make it sound like the end product will be T though, especially with the last sentence. The first two declarations will not be the same for an rvalue, since one will incur a move that the other does not.
OK,I meant what I wrote but what I wrote seems, indeed, not be accurate although in practice it probably doesn't matter (because the copy or move will normally be elided anyway). I'll update the response correspondingly.
"I know you think you understand what you thought I said, but I am not sure you realize that what you heard is not what I meant." -- Alan Greenspan addressing a question from a student during a presentation.
3

This is a good question -- the first part: pass-by-value or use forwarding. I think the second part (having FunctorT& as an argument) has been reasonably answered.

My advice is this: use forwarding only when the function object is known, in advance, to modify values in its closure (or capture list). Best example: std::shuffle. It takes a Uniform Random Number Generator (a function object), and each call to the generator modifies its state. The function object is forwarded into the algorithm.

In every other case, you should prefer to pass by value. This does not prevent you from capturing locals by reference and modifying them within your lambda function. That will work just like you think it should. There should be no overhead for copying, as Dietmar says. Inlining will also apply and references may be optimized out.

Improve this answer

3 Comments

When you say there should be no overhead for copying, you mean that in practice the copies will be optimized out or that semantically copies aren't made?
Copies should be elided. Optimized away.
The only by-value copy that can be elided is an rvalue conceptually created at call site, which can be constructed as the argument. Beyond that, copies of by-value args, e.g. cascaded to other function calls, absolutely can't be elided. Each function must get its own copy, which must live separately from the original: it must not track concurrent changes to its source; and for non-const by-value args, it must conversely be alterable without affecting the original. So here, copies are guaranteed. Use a forwarding reference, always. It's either free or saves pointless copies. Why pay ever?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.