3 ms·

That is the right approach IMO. What I'm basically saying is "more of this". It's clearly possible for C++ compilers to do this in many more cases. They already

That is the right approach IMO. What I'm basically saying is "more of this". It's clearly possible for C++ compilers to do this in many more cases. They already do most of the hard parts just to produce some of the error messages that they do. Why not use that knowledge more often to help the programmer instead of burdening them?

mehrdadn 8y ago
> It's clearly possible for C++ compilers to do this in many more cases. [...] Why not use that knowledge more often to help the programmer instead of burdening them? Because it'd break code. I explained in another comment here: https://news.ycombinator.com/item?id=19634423 https://news.ycombinator.com/item?id=19634423
- notacoward 8y ago
  > Because it'd break code. Then that's an indictment of the decisions that led to such code being written in the first place.
  - mehrdadn 8y ago
    Only if you're quick to judge without understanding why such code is and will continue to be written.
    - notacoward 8y ago
      You're pretty quick to assume I don't. Believe me, I understand. I just don't agree that it's a good idea to mix up object lifetimes and execution context by using destructors to "magically" release locks etc. It never was. The mistakes were made years ago. I'm not quick to judge (in this case). I'm judging after careful consideration, because I know the difference between good and bad patterns. The ones being hasty are those who mistake their own comfort level with something (often because they know nothing else) for actual merit.
      - mehrdadn 8y ago
        Your proposed better pattern to follow when one needs a finally block in C++ is...?
        notacoward 8y ago
        I already mentioned "defer" as in Go or Zig. It's explicitly tied to scope exit, not object lifetime, so it avoids all of the problems inherent in confusing the two.
        mehrdadn 8y ago
        I didn't ask what language you would use. I asked what you would do in C++, given you're criticizing people for writing such code in the language. If you're put so much thought into this problem like you claim then surely you must have a better alternative in mind.
        notacoward 8y ago
        I don't care what people "would do" in C++ today, because my whole point is that C++ started down this bad path years ago. I'm not criticizing people for writing such code. I'm criticizing the standards-makers who made such hacks (seem) necessary. It's not about having put thought into it either. Lots of people had put plenty of thought into it when the various versions of C++ were standardized. This is about making the right choices from among the alternatives available, and that was not done. Demanding a solution that is both applicable to C++ as it exists today and yet not in C++ today is demanding two contradictory things. It's demanding that the same thing both did and didn't happen. It's dishonest. You want a suggestion? Adopt "defer" for the next version of C++. It's the best we can do. We can't change the past, but we can learn from it if we don't get stuck trying to excuse past mistakes and attack those who point them out.
      - j16sdiz 8y ago
        RAII is one of the core language feature of C++. Replacing it with defer or GC will surely break existing programs. It would make sense ONLY if you want to have a new language.
IshKebab 8y ago
Because the compiler can't always know when moving a value is acceptable.

mehrdadn 8y ago

> It's clearly possible for C++ compilers to do this in many more cases. [...] Why not use that knowledge more often to help the programmer instead of burdening them? Because it'd break code. I explained in another comment here: https://news.ycombinator.com/item?id=19634423 https://news.ycombinator.com/item?id=19634423

notacoward 8y ago
> Because it'd break code. Then that's an indictment of the decisions that led to such code being written in the first place.
- mehrdadn 8y ago
  Only if you're quick to judge without understanding why such code is and will continue to be written.
  - notacoward 8y ago
    You're pretty quick to assume I don't. Believe me, I understand. I just don't agree that it's a good idea to mix up object lifetimes and execution context by using destructors to "magically" release locks etc. It never was. The mistakes were made years ago. I'm not quick to judge (in this case). I'm judging after careful consideration, because I know the difference between good and bad patterns. The ones being hasty are those who mistake their own comfort level with something (often because they know nothing else) for actual merit.
    - mehrdadn 8y ago
      Your proposed better pattern to follow when one needs a finally block in C++ is...?
      - notacoward 8y ago
        I already mentioned "defer" as in Go or Zig. It's explicitly tied to scope exit, not object lifetime, so it avoids all of the problems inherent in confusing the two.
        mehrdadn 8y ago
        I didn't ask what language you would use. I asked what you would do in C++, given you're criticizing people for writing such code in the language. If you're put so much thought into this problem like you claim then surely you must have a better alternative in mind.
        notacoward 8y ago
        I don't care what people "would do" in C++ today, because my whole point is that C++ started down this bad path years ago. I'm not criticizing people for writing such code. I'm criticizing the standards-makers who made such hacks (seem) necessary. It's not about having put thought into it either. Lots of people had put plenty of thought into it when the various versions of C++ were standardized. This is about making the right choices from among the alternatives available, and that was not done. Demanding a solution that is both applicable to C++ as it exists today and yet not in C++ today is demanding two contradictory things. It's demanding that the same thing both did and didn't happen. It's dishonest. You want a suggestion? Adopt "defer" for the next version of C++. It's the best we can do. We can't change the past, but we can learn from it if we don't get stuck trying to excuse past mistakes and attack those who point them out.
    - j16sdiz 8y ago
      RAII is one of the core language feature of C++. Replacing it with defer or GC will surely break existing programs. It would make sense ONLY if you want to have a new language.

IshKebab 8y ago

Because the compiler can't always know when moving a value is acceptable.