3 ms·

> using `new` and assigning to a raw pointer is a sign that the C++ developer is managing memory manually and is likely to hit a lot of problems including memor

> using `new` and assigning to a raw pointer is a sign that the C++ developer is managing memory manually and is likely to hit a lot of problems including memory leaks There is no need to badmouth all c++ developers. Plenty of us can keep our memory straight just fine. just because you don't like pointers, does not mean the rest of us can't use them perfectly safely.

pjmlp 7y ago
The rest of us isn't that big number according to Microsoft and Google security reports. I surely have my share of C++ pointer mistakes done since I got hold of C++ARM and Turbo C++, after years of Assembly and Turbo Pascal programming. Not only C++, but any other language with manual memory management, because keeping track of where everything is going manually, just doesn't scale.
asdfasgasdgasdg 7y ago
I think the evidence is pretty clear that programmers can't, in general, use bare pointers properly. The very best write use after free, double free, stack smashers, and all manner of other memory related bugs. We can see the evidence of this fact in the CVEs, the syzkaller bugs, etc. If you haven't been bitten by a serious instance of one of these, then you just haven't written very much C++. IMO the debate about whether programmers can safely handle bare pointers is over. They can't. The only question is whether smart pointers help enough to make the extra line noise worth it.
- choeger 7y ago
  And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers? It is ok to stay above a certain level of abstractions consciously, but stating that one cannot go below safely is just steadying mediocrity.
  - lmm 7y ago
    > And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers? One cannot do any of those things safely by hand. Compilers, kernels, and embedded systems do indeed do these things; they also have bugs.
    - choeger 7y ago
      You are contradicting yourself. If one cannot do these things safely by hand, then noone can implement the automatic abstractions either.
      - rcxdude 7y ago
        You cannot safely control an internal combustion engine's valve timings by hand, but it is clearly possible to implement this automatically (and fairly simply). Some things are much easier for machines to do than humans, even though the machines are designed and build by humans.
  - pjmlp 7y ago
    > Is there a certificate to get into that club? There is and the large majority fails at it, as proven by the CVE database, in spite the rigorous process to contribute code to the Linux kernel for example.
    - choeger 7y ago
      I call bullshit. And arrogant bullshit at that. The wast majority of bare metal components is highly functional and relatively bug free.
      - pjmlp 7y ago
        You can call whatever you like, CVE database, yearly security reports, and OS release notes from all major OSes provide the necessary facts. Sadly liability still isn't a thing on software development.
SamReidHughes 7y ago
The statement you quoted is simply a fact, not badmouthing. If there is any badmouthing by implication, it wouldn't be "all" C++ developers, just those who don't realize they're doing something spooky when their code looks like Foo *foo = new Foo.
inetknght 7y ago
> just because you don't like pointers, does not mean the rest of us can't use them perfectly safely. I actually use pointers quite safely. I just no longer see a need to ever return an allocation from `new` to a raw pointer unless I'm implementing my own pointer class. Herb Sutter's correct [0]. `std::unique_ptr` or `std::shared_ptr` or some other pointer container should __always__ hold new-allocated objects. Just like you should __always__ wear your seatbelt. It's no danger to you or anyone else, it's slightly inconvenient, and it saves a metric ton of headaches about "what if?". Because in reality a pointer container explicitly marks the scope of the allocation and if you're not wanting to use C++'s scoping rules then why are you using C++? [0] https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE

pjmlp 7y ago

The rest of us isn't that big number according to Microsoft and Google security reports. I surely have my share of C++ pointer mistakes done since I got hold of C++ARM and Turbo C++, after years of Assembly and Turbo Pascal programming. Not only C++, but any other language with manual memory management, because keeping track of where everything is going manually, just doesn't scale.

asdfasgasdgasdg 7y ago

I think the evidence is pretty clear that programmers can't, in general, use bare pointers properly. The very best write use after free, double free, stack smashers, and all manner of other memory related bugs. We can see the evidence of this fact in the CVEs, the syzkaller bugs, etc. If you haven't been bitten by a serious instance of one of these, then you just haven't written very much C++. IMO the debate about whether programmers can safely handle bare pointers is over. They can't. The only question is whether smart pointers help enough to make the extra line noise worth it.

choeger 7y ago
And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers? It is ok to stay above a certain level of abstractions consciously, but stating that one cannot go below safely is just steadying mediocrity.
- lmm 7y ago
  > And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers? One cannot do any of those things safely by hand. Compilers, kernels, and embedded systems do indeed do these things; they also have bugs.
  - choeger 7y ago
    You are contradicting yourself. If one cannot do these things safely by hand, then noone can implement the automatic abstractions either.
    - rcxdude 7y ago
      You cannot safely control an internal combustion engine's valve timings by hand, but it is clearly possible to implement this automatically (and fairly simply). Some things are much easier for machines to do than humans, even though the machines are designed and build by humans.
- pjmlp 7y ago
  > Is there a certificate to get into that club? There is and the large majority fails at it, as proven by the CVE database, in spite the rigorous process to contribute code to the Linux kernel for example.
  - choeger 7y ago
    I call bullshit. And arrogant bullshit at that. The wast majority of bare metal components is highly functional and relatively bug free.
    - pjmlp 7y ago
      You can call whatever you like, CVE database, yearly security reports, and OS release notes from all major OSes provide the necessary facts. Sadly liability still isn't a thing on software development.

SamReidHughes 7y ago

The statement you quoted is simply a fact, not badmouthing. If there is any badmouthing by implication, it wouldn't be "all" C++ developers, just those who don't realize they're doing something spooky when their code looks like Foo *foo = new Foo.

inetknght 7y ago

> just because you don't like pointers, does not mean the rest of us can't use them perfectly safely. I actually use pointers quite safely. I just no longer see a need to ever return an allocation from `new` to a raw pointer unless I'm implementing my own pointer class. Herb Sutter's correct [0]. `std::unique_ptr` or `std::shared_ptr` or some other pointer container should __always__ hold new-allocated objects. Just like you should __always__ wear your seatbelt. It's no danger to you or anyone else, it's slightly inconvenient, and it saves a metric ton of headaches about "what if?". Because in reality a pointer container explicitly marks the scope of the allocation and if you're not wanting to use C++'s scoping rules then why are you using C++? [0] https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE