4 ms·

C++ seems to have this never-ending cycle where it keeps introducing fixes for deficiencies that people have found a way to work around, but which in turn creat

by human20190310 7y ago

C++ seems to have this never-ending cycle where it keeps introducing fixes for deficiencies that people have found a way to work around, but which in turn create their own problems... E.g. C++11's std::move, which may have partially solved the problem of copying objects (which everyone had their own way of avoiding anyway), but introduced its own puzzles about the validity of the objects after the move.

kllrnohj 7y ago
> but introduced its own puzzles about the validity of the objects after the move. In practice it's really not a puzzle. Most of the time you're using std::move it's because you don't care about the object you moved from, you're about to drop it on the floor. The other times you either manually reset it or just read the docs of the type to find out what it says the state will be after move. It's not really any different from any other method documentation on a class. unique_ptr (or other unique_* types) are vastly worth it, which did not otherwise have a way to work prior to C++11's move semantics.
- human20190310 7y ago
  It's a puzzle; observe 8 years of people (with 5 and 6 digit reputation!) debating the details in the comments: https://stackoverflow.com/questions/3413470/what-is-stdmove-and-when-should-it-be-used https://stackoverflow.com/questions/3413470/what-is-stdmove-...
  - Asooka 7y ago
    That's an incredibly open-ended question, so of course there's debate. I'm amazed it hasn't been locked already.
einpoklum 7y ago
> C++ seems to have this never-ending cycle where it keeps introducing fixes for deficiencies that people have found a way to work around, but which in turn create their own problems... The fixes don't create their own problems. They can and are used as intended, usually with little or no problems. What does happen is that they open up new possibilities and program expressiveness, and those have new issues/challenges.

kllrnohj 7y ago

> but introduced its own puzzles about the validity of the objects after the move. In practice it's really not a puzzle. Most of the time you're using std::move it's because you don't care about the object you moved from, you're about to drop it on the floor. The other times you either manually reset it or just read the docs of the type to find out what it says the state will be after move. It's not really any different from any other method documentation on a class. unique_ptr (or other unique_* types) are vastly worth it, which did not otherwise have a way to work prior to C++11's move semantics.

human20190310 7y ago
It's a puzzle; observe 8 years of people (with 5 and 6 digit reputation!) debating the details in the comments: https://stackoverflow.com/questions/3413470/what-is-stdmove-and-when-should-it-be-used https://stackoverflow.com/questions/3413470/what-is-stdmove-...
- Asooka 7y ago
  That's an incredibly open-ended question, so of course there's debate. I'm amazed it hasn't been locked already.

einpoklum 7y ago

> C++ seems to have this never-ending cycle where it keeps introducing fixes for deficiencies that people have found a way to work around, but which in turn create their own problems... The fixes don't create their own problems. They can and are used as intended, usually with little or no problems. What does happen is that they open up new possibilities and program expressiveness, and those have new issues/challenges.