Modern C++ Won't Save Us

Re:Modern C++ Won't Save Us by arcticbull on Monday April 22, 2019 @11:18PM (#19725296)

I'm not really arguing about the value of that code either, just that it's probably wrong, probably trivially breakable due to the sheer mountain of complexity underlying it. The compiler just happened to let it through because it can't help you. The language doesn't give it enough information to do so effectively.

Just off the top of my head, std::move doesn't... move [1]. It just returns an, I kid you not "static_cast<typename remove_reference<T>::type&&>(t)" without doing... anything. You can keep on using the old value probably, silently, until out of the blue, it stops working one day. Then you're super, duper sad. Even modern language features are, I don't want to say lies, but "hopes and dreams" the compiler can't enforce. It's like if you really wished C++ had Rust's features, but you can't without breaking things, so you give it your best shot, which ends up just creating yet more complexity.

Rust's answer is...

  let x = Value::new();
  let y = x;
  let z = x; (COMPILER ERROR: X GOT MOVED INTO Y)

C++'s modern features are to Rust's equivalents what the ruined fresco [2] was to the original. If you stand far enough back, it's basically right. If you get up close it's hilariously and trivially broken.

It takes a lot of gymnastics to call this language approachable or understandable. It's basically a coal powered car made of foot-guns. That doesn't mean it's not a car, or that it won't get you where you're trying to go, I'm just saying it's an open question how many pieces you'll arrive in.

[1] http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move...

[2] https://www.npr.org/sections/thetwo-way/2012/09/20/161466361...

[ Parent | on HN ]

Re:Modern C++ Won't Save Us by masklinn on Tuesday April 23, 2019 @02:14AM (#19726031)

> Just off the top of my head, std::move doesn't... move [1].

I mean that makes sense in a (somewhat nonsensical) way, std::move is a marker for "you can move this thing if you want".

The much weirder part is that even if a value is moved it's not moved, it's carved out, you get to keep a shell value in a "valid but unspecified state". Reusing that value (which the compiler won't prevent) may or may not be UB depending on the exact nature of the operation and state.

Oh and of course that a change / override to the caller and recompile can change the behaviour of the callsite entirely (e.g. a previously moved value is not moved anymore, or the other way around) but that's pretty common for C++.

[ Parent | on HN ]