Why this code fails to compile with gcc 4.8.5 while it compiles fine with clang

Question

#include<iostream>                                                                                                                                    

using namespace std;                                                                                                                                  

int main()                                                                                                                                            
{                                                                                                                                                     
   const int k = 10;                                                                                                                                  

   // Capture k by value                                                                                                                              
   auto myl = [k] (int k) { cout << " ++k=" << ++k ; };                                                                                            

   myl(k+10);                                                                                                                                             
}

Error below

lamda.cpp: In lambda function:
lamda.cpp:10:50: error: increment of read-only variable âkâ
    auto myl = [k] (int k) { cout << " ++K=" << ++k ; };

clearly what I am referring to is local variable K and not const member K.

Are you sure you can compile it with Clang? You have names interception, since you are sharing constant 'k' with the lambda function formal parameter called k. If clang able to compile it - you probably can test it with GCC 5+ with `-std=c++14` key. In any case you have an error in your code. — Victor Gubin, Jun 29 '18 at 11:25
It fails with all the gcc compiler except 8.1 , we can see it here .https://godbolt.org/g/o355oQ — user8063157, Jun 29 '18 at 11:31
Perhaps relevant is that GCC 8.1 supports certain features of C++2a, so perhaps it's intentional. — acraig5075, Jun 29 '18 at 11:34
This has nothing to do with c++2a clang compiles it from version 3.4.1 onwards https://godbolt.org/g/B46sX9 — user8063157, Jun 29 '18 at 11:36

score 4 · Accepted Answer · edited Jun 20 '20 at 09:12

This isn't quite as straightforward as it might seem. A lambda that captures k by copy is mostly equivalent to a struct object whose closure type has a member named k, and with an operator() whose definition uses the specified parameters and body. If that were technically true, sure, we know that a function parameter hides a class member.

Except that's not how the Standard actually defines lambdas. Instead, it says that any entity captured by value corresponds to an unnamed member of the closure type. In the lambda body, name lookup looks in the lambda's enclosing scope, not the scope of the closure type. If that name lookup finds an entity captured by copy, the compiler must internally transform that usage of the name to a usage of the unnamed member instead. In C++11 and C++14, these rules didn't clearly specify how lambda parameter names fit into that name lookup scheme, and as a result, different compilers and compiler versions didn't agree on behavior in cases like this where a captured entity and a lambda parameter had the same name.

With Defect Resolution 2211, C++17 solved the issue by just making it illegal:

[expr.prim.lambda.capture]/5:

If an identifier in a simple-capture appears as the declarator-id of a parameter of the lambda-declarator's parameter-declaration-clause, the program is ill-formed. [ Example:
void f() {
  int x = 0;
  auto g = [x](int x) { return 0; } // error: parameter and simple-capture have the same name
}
-- end example ]

(See also the same paragraph in the current draft mirror.)

Then this is a Bug with gcc 8.1 and clang I suppose , Which need to be reported. Clang: https://godbolt.org/g/B46sX9 gcc 8.1: https://godbolt.org/g/7p9tyZ — user8063157, Jun 29 '18 at 12:09

Why this code fails to compile with gcc 4.8.5 while it compiles fine with clang

1 Answers1