4 ms·

> It is. There is no point in arguing otherwise. Well, I don’t know how to respond to this. I clarified what the rules actually are (< 1 paragraph) and followi

> It is. There is no point in arguing otherwise. Well, I don’t know how to respond to this. I clarified what the rules actually are (< 1 paragraph) and following them blindly leads to correct results. You’ve brought in a whole bunch of nonsense about why C++ has become complex as a language - it’s not wrong but I’m failing to connect the dots as to how the rule of 0 itself is hard to follow or complex. I’m kind of taking as a given that whoever is writing the code is mildly familiar enough with C++ to understand RAII & is trying to apply it correctly. > The rule of 5 is a nice rule of thumb to allow developers to have a simple mental model over what they need to do to avoid a long list of issues, but you still have no control over what you’re doing. Things work, but work by sheer coincidence. First, as I’ve said multiple times, it’s the rule of 0. That’s the rule to follow to get correct composition of resource ownership & it’s super simple. As for not having control, I really fail to see how that is - C++ famously gives you too much control and that’s the problem. As for things working by sheer coincidence, that’s like your opinion. To me “coincidence” wouldn’t explain how many lines of C++ code are running in production. Look, I think C++ has a lot of warts which is why I prefer Rust these days. But the rule of 0 is not where I’d say C++’s complexity lies - if you think that is the case, I’d recommend you use another language because if you can’t grok the rule of 0, the other footguns that lie in wait will blow you away to smithereens.

bruce343434 2y ago
> nonsense ... not wrong So it's not nonsense? I think GP clearly laid out the base principles that lead to emergent complexity . GP calls this "coincidence" to convey the feeling of lots of complexity just narrowly avoiding catastrophe in a process that is hard to grok for someone getting into C++. GP also gave some scenarios in which the rule of 0 no longer applies and you now simply have to follow some other rule. "just follow the rule" is not very intuitive advice. The rule may be simple to follow but the foundations on which it rests are pretty complicated, which makes the entire rule complicated in my worldview and also that of GP. In your view, the rule is easy to follow therefore simple. Let's agree to disagree on that. Again, being told "you need to just follow this arbitrary rule to fix all these sudden compiler errors" doesn't inspire confidence in ones code, hence (I think) the usage of "coincidence". If I were using such a language, I'd certainly feel a bit nervous and unsure.
- deleted 2y ago
  [deleted]
- astrobe_ 2y ago
  > GP calls this "coincidence" to convey the feeling of lots of complexity just narrowly avoiding catastrophe in a process that is hard to grok for someone getting into C++ I think that's what they said themselves: >> It all makes absolutely sense if you are mindful of the design requirements. But if you just start to onboard onto C++ and barely know what a copy constructors is, all these aspects are arcane and sadistic IMO not knowing why something works (in any language) is an unpleasant feeling. Then if you have the chance you can look under the hood, read things - it's exactly why I'm reading this thread - and little by little get a better understanding. That's called gaining experience. > Again, being told "you need to just follow this arbitrary rule to fix all these sudden compiler errors" doesn't inspire confidence in ones code, hence (I think) the usage of "coincidence" That's exactly what other languages like Haskell or Rust are praised for. Why does C++ receive a different treatment when it tries to do the same thing instead of crashing on you at runtime, for once?
  - marcosdumay 2y ago
    > That's exactly what other languages like Haskell or Rust are praised for. You making a trivial change, and suddenly there are entire new classes of bugs all over your code is an aspect that does really not receive any praise. People using those two languages work hard on avoiding that situation, and it clearly feels like a failure when it happens. The part about pointing problems at compile time so the developer will know it sooner is great. And I imagine is the part you are talking about. But the GP was talking about the other part of the issue.
rcxdude 2y ago
In addition, it's actually pretty easy in most cases where you do what a non-trivial constructor and destructor to just delete the other 3, and wrap it in unique_ptr or similar to manage the hard parts. I think I've defined all 5 approximately once, and mostly for the fun of it in a side project.

bruce343434 2y ago

> nonsense ... not wrong So it's not nonsense? I think GP clearly laid out the base principles that lead to emergent complexity . GP calls this "coincidence" to convey the feeling of lots of complexity just narrowly avoiding catastrophe in a process that is hard to grok for someone getting into C++. GP also gave some scenarios in which the rule of 0 no longer applies and you now simply have to follow some other rule. "just follow the rule" is not very intuitive advice. The rule may be simple to follow but the foundations on which it rests are pretty complicated, which makes the entire rule complicated in my worldview and also that of GP. In your view, the rule is easy to follow therefore simple. Let's agree to disagree on that. Again, being told "you need to just follow this arbitrary rule to fix all these sudden compiler errors" doesn't inspire confidence in ones code, hence (I think) the usage of "coincidence". If I were using such a language, I'd certainly feel a bit nervous and unsure.

deleted 2y ago
[deleted]
astrobe_ 2y ago
> GP calls this "coincidence" to convey the feeling of lots of complexity just narrowly avoiding catastrophe in a process that is hard to grok for someone getting into C++ I think that's what they said themselves: >> It all makes absolutely sense if you are mindful of the design requirements. But if you just start to onboard onto C++ and barely know what a copy constructors is, all these aspects are arcane and sadistic IMO not knowing why something works (in any language) is an unpleasant feeling. Then if you have the chance you can look under the hood, read things - it's exactly why I'm reading this thread - and little by little get a better understanding. That's called gaining experience. > Again, being told "you need to just follow this arbitrary rule to fix all these sudden compiler errors" doesn't inspire confidence in ones code, hence (I think) the usage of "coincidence" That's exactly what other languages like Haskell or Rust are praised for. Why does C++ receive a different treatment when it tries to do the same thing instead of crashing on you at runtime, for once?
- marcosdumay 2y ago
  > That's exactly what other languages like Haskell or Rust are praised for. You making a trivial change, and suddenly there are entire new classes of bugs all over your code is an aspect that does really not receive any praise. People using those two languages work hard on avoiding that situation, and it clearly feels like a failure when it happens. The part about pointing problems at compile time so the developer will know it sooner is great. And I imagine is the part you are talking about. But the GP was talking about the other part of the issue.

rcxdude 2y ago

In addition, it's actually pretty easy in most cases where you do what a non-trivial constructor and destructor to just delete the other 3, and wrap it in unique_ptr or similar to manage the hard parts. I think I've defined all 5 approximately once, and mostly for the fun of it in a side project.