4 ms·

It's more like C++ made by that ISO committee and C++ used by actual users of C++ needs a divorce. They are so far up in the clouds adding features to language

by 112233 2y ago

It's more like C++ made by that ISO committee and C++ used by actual users of C++ needs a divorce. They are so far up in the clouds adding features to language that mostly only help them to write less embarrasing standard library code, it hurts to watch sometimes. Remember discussions that led to std::bit_cast? How absolutely everyone who processes binary data is wrong, because object of type, say, "unsigned" does not exist before it is created, so everyone casting pointers to parse packets is wrong, and only commitee is right? It is doubly sad to see them claim compatibility to C (C++ is absolutely not compatible to C) as a reason for some features, or single pass compilation as a reason for others... [edit] To clarify, on one hand, a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") or not being able to add friends without editing source ("debugging? we think it is overrated"), but then they go and proclaim basically all existing code that processes structured binary data as non-conformant.

nextaccountic 2y ago
> a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") What does this code do? Is this referring to a previously defined x, now shadowed by a new x? Like this int x = 1; int x = x; If yes, Rust has this feature too. And in Rust, shadowing variables is very idiomatic and is sometimes used to create safe abstractions.
- 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 ago
    I 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 ago
      It'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;} | ~ ^

by 112233 2y ago

nextaccountic 2y ago

> a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") What does this code do? Is this referring to a previously defined x, now shadowed by a new x? Like this int x = 1; int x = x; If yes, Rust has this feature too. And in Rust, shadowing variables is very idiomatic and is sometimes used to create safe abstractions.

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 ago
  I 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 ago
    It'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;} | ~ ^