Issue: passing a generic lambda (to a template function) that captures this
and calls a member function of this
without an explicit this->
does not compile on gcc. If the lambda is not generic, or if the lambda is not passed to any other function but called in place, it compiles withoit an explicit this->
. Clang is cool with the code in all situations.
Time for another round of clang vs gcc. Who's right?
Wandbox example
template<typename TF>
void call(TF&& f)
{
f(1);
}
struct Example
{
void foo(int){ }
void bar()
{
call([this](auto x){ foo(x); });
}
};
int main()
{
Example{}.bar();
return 0;
}
bar()
= call([this](auto x){ foo(x); });
error: cannot call member function 'void Example::foo(int)' without object call([this](auto x){ foo(x); });`
bar()
= call([this](auto x){ this->foo(x); });
bar()
= call([this](int x){ foo(x); });
bar()
= [this](auto x){ foo(x); }(1);
Why is the this->
necessary only in the case of a generic lambda?
Why is the this->
not necessary if the lambda isn't passed to call
?
Who is being non standard-compliant?
This is a gcc bug. From [expr.prim.lambda]:
The lambda-expression’s compound-statement yields the function-body (8.4) of the function call operator, but for purposes of name lookup (3.4), determining the type and value of
this
(9.3.2) and transforming id-expressions referring to non-static class members into class member access expressions using(*this)
(9.3.1), the compound-statement is considered in the context of the lambda-expression. [ Example:struct S1 { int x, y; int operator()(int); void f() { [=]()->int { return operator()(this->x + y); // equivalent to S1::operator()(this->x + (*this).y) // this has type S1* }; } };
—end example ]
Since in your example you capture this
, the name lookup should include class members of Example
, which should therefore find Example::foo
. The lookup performed is identical to what would happen if foo(x)
appeared in the context of the lambda-expression itself, that is if the code looked like:
void bar()
{
foo(x); // clearly Example::foo(x);
}
At least this bug has a very simple workaround as indicated in the question: just do this->foo(x);
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With