4 ms·

Indeed it's already grown `async` and `?` since 1.0. But I love those features, they're a good thing. In Rust, the compiler still checks everything. I can't mi

Indeed it's already grown `async` and `?` since 1.0. But I love those features, they're a good thing. In Rust, the compiler still checks everything. I can't mis-use async or the question mark operator and accidentally make my code unsafe. In C++, I'm expected to know everything about every feature I use, so I have to be paranoid. Sure I remember that unique_ptr isn't atomic, do my juniors remember that? Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings. And I myself don't even remember the rules for SFINAE or `move` in full. Not to mention that OpenCV's mix of shallow and deep copying for matrices casually breaks `const`. In Rust, more surface area is just more Lego bricks. If two Legos snap together, you're safe. If they don't, don't force them. C++ expects you to force everything and take responsibility for not being a human encyclopedia of the language.

no_wizard 3y ago
Is it not possible to use a linter with C++ that can tell you when you have done X or Y incorrectly? surely, there is tooling that can help right?
- thesuperbigfrog 3y ago
  It is possible to use C++ with a linter to help detect errors, but linters do not catch all errors nor do linters always understand what you are trying to do. Most approaches to using C or C++ safely involve throwing out large portions of the language and disallowing features that are easy to misuse or problematic to analyze for safety.
- foooorsyth 3y ago
  Not all of the issues you can create in C++ are visible at compile time. That’s kind of the point. A lot of the time you’re going to need to lean on Valgrind. And that’s AFTER you shipped a fatal crash and you’re parsing a tombstone.
- UncleMeat 3y ago
  Often no, for multiple reasons. Separate compilation means that even if you write an interprocedural static analysis system (quite a bit more complex than what most people would call a linter), you still run into oodles of hard boundaries where you can't look into other functions. Fixing this requires explicit annotations all over the place to even have a chance. C++ is also a remarkably complex language in terms of aliasing relationships. There are a bazillion ways you can make two names alias each other. This gives you a few options when writing an analysis. You can be sound and do weak updates everywhere, which means your alarms will basically never be confident. You can be unsound and assume no aliasing, which means that you've got a lot of false alarms. You also can't really make a rule "don't ever create aliasing relationships" because they are often idiomatic C++. And finally, the key properties that people really deeply care about like heap lifetimes fundamentally involve complex reasoning about both temporal properties, dataflow, and heap shape. All of these are hairy static analysis problems. In combination, a nightmare.
- ReactiveJelly 3y ago
  Maybe. But my employer doesn't have those tools. Assuming we're a median team, then half of all c++ teams don't do any static analysis or even know how to use valgrind properly. (The only tools that looked useful to me were the ones that incurred a thousand x slowdown, and our code is too crappy to run correctly at different speeds)
AnimalMuppet 3y ago
Almost every feature is a good thing. But the total quantity can become a bad thing, because the interactions between the features become more and more complicated. It's almost like features have values proportional to the number of features, but they have costs proportional to the square of the number of features. You eventually reach the point where new features add more cost than they add value. But it's not that simple, because each new feature adds value to a subset, but adds costs to everyone. If the subset is vocal, they often get what they want, even if it's a net loss for all users taken as a whole. So the trick is, first, to stop adding features once the costs outweigh the benefits, and second, given that you have only a finite number of features that you can add before you reach that point, to add the total set of features that are going to make the most valuable language.
- ReactiveJelly 3y ago
  Yes but actually no. In rust the compiler handles interactions between features for you. C and c++ don't. Per my previous Lego analogy.
protomolecule 3y ago
"Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings." Seriously?

no_wizard 3y ago

Is it not possible to use a linter with C++ that can tell you when you have done X or Y incorrectly? surely, there is tooling that can help right?

thesuperbigfrog 3y ago
It is possible to use C++ with a linter to help detect errors, but linters do not catch all errors nor do linters always understand what you are trying to do. Most approaches to using C or C++ safely involve throwing out large portions of the language and disallowing features that are easy to misuse or problematic to analyze for safety.
foooorsyth 3y ago
Not all of the issues you can create in C++ are visible at compile time. That’s kind of the point. A lot of the time you’re going to need to lean on Valgrind. And that’s AFTER you shipped a fatal crash and you’re parsing a tombstone.
UncleMeat 3y ago
Often no, for multiple reasons. Separate compilation means that even if you write an interprocedural static analysis system (quite a bit more complex than what most people would call a linter), you still run into oodles of hard boundaries where you can't look into other functions. Fixing this requires explicit annotations all over the place to even have a chance. C++ is also a remarkably complex language in terms of aliasing relationships. There are a bazillion ways you can make two names alias each other. This gives you a few options when writing an analysis. You can be sound and do weak updates everywhere, which means your alarms will basically never be confident. You can be unsound and assume no aliasing, which means that you've got a lot of false alarms. You also can't really make a rule "don't ever create aliasing relationships" because they are often idiomatic C++. And finally, the key properties that people really deeply care about like heap lifetimes fundamentally involve complex reasoning about both temporal properties, dataflow, and heap shape. All of these are hairy static analysis problems. In combination, a nightmare.
ReactiveJelly 3y ago
Maybe. But my employer doesn't have those tools. Assuming we're a median team, then half of all c++ teams don't do any static analysis or even know how to use valgrind properly. (The only tools that looked useful to me were the ones that incurred a thousand x slowdown, and our code is too crappy to run correctly at different speeds)

AnimalMuppet 3y ago

Almost every feature is a good thing. But the total quantity can become a bad thing, because the interactions between the features become more and more complicated. It's almost like features have values proportional to the number of features, but they have costs proportional to the square of the number of features. You eventually reach the point where new features add more cost than they add value. But it's not that simple, because each new feature adds value to a subset, but adds costs to everyone. If the subset is vocal, they often get what they want, even if it's a net loss for all users taken as a whole. So the trick is, first, to stop adding features once the costs outweigh the benefits, and second, given that you have only a finite number of features that you can add before you reach that point, to add the total set of features that are going to make the most valuable language.

ReactiveJelly 3y ago
Yes but actually no. In rust the compiler handles interactions between features for you. C and c++ don't. Per my previous Lego analogy.

protomolecule 3y ago

"Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings." Seriously?