3 ms·
No, it is referring to the x that is being initialized, and uses uninitialized memory to initialize x. -Wall will even print a helpful reminder. Compare: i
by 112233 2y ago
No, it is referring to the x that is being initialized, and uses uninitialized memory to initialize x. -Wall will even print a helpful reminder. Compare:
int f(int x) {
int x = x; // second x is not argument
return x;
}
and:
int f(int x){
// here second x is argument
return [x=x] { return x; }();
}
- nextaccountic 2y agoI don't understand, in the two cases there is a local x shadowing a function parameter also named x.. in the first case it is a local variable that shadows the parameter, in the second it's a closure binding. Are you sure that, in the first example, in int x = x, the local variable x doesn't get initialized with the function parameter x, but rather gets initialized with itself (uninitialized memory)? Is this instant UB? Is the second example actually legit, and initializes the closure bound variable with the x function parameter?
- 112233 2y agoIt's even more fun than I remember. This compiles without warnings with "gcc -Wall", and produces an error (declaration of x shadows a parameter) if f4 is uncommented struct S { int x; int f1() { int x = x; return x; } int f2(int x) { return [x=x]{return x;}(); } int f3(int x) { if (int x=x) return x; return x;} // int f4(int x) { int x=x; return x; } }; int main(){} clang warns a bit with -Wall a.cpp:5:26: warning: variable 'x' is uninitialized when used within its own initialization [-Wuninitialized] 5 | int f3(int x) { if (int x=x) return x; return x;} | ~ ^