4 ms·

> Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. No, it isn't. That's flagged by default settin

> Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. No, it isn't. That's flagged by default settings of most static code analysis tools, and it requires explicitly going against the whole point of explicitly assigning ownership of an object.

UncleMeat 4y ago
Ownership is about lifetimes, not use. You are going to have a highly constrained design if nothing can access any pointer that it does not directly own. Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?
- simplotek 4y ago
  > Ownership is about lifetimes, not use. You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself. It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants. Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue. You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.
  - UncleMeat 4y ago
    You didn't answer my question. What static analyzers? "Never pass a non-owning reference to anything ever" is ludicrous.

UncleMeat 4y ago

Ownership is about lifetimes, not use. You are going to have a highly constrained design if nothing can access any pointer that it does not directly own. Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?

simplotek 4y ago
> Ownership is about lifetimes, not use. You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself. It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants. Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue. You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.
- UncleMeat 4y ago
  You didn't answer my question. What static analyzers? "Never pass a non-owning reference to anything ever" is ludicrous.