On Sunday, 11 October 2015 at 23:08:58 UTC, Manu wrote:
Incidentally, I tried to use shared_ptr initially, but it took about 20 minutes before I realised I had to pass an rc pointer from a method... Since rc is a wrapper, like you said above, you lose it as soon as you're within a method. I then had to write an invasive rc implementation and hard create a new rc instance from 'this', all over the place. Seriously, I don't understand how anyone can say shared_ptr is a success. It's a massive kludge, and it alone has me firmly convinced that rc is weak, inconvenient, and highly complicated without language support.
If you use shared_ptr, what typically happens is that you use shared_ptr everywhere and naked pointers pretty much disappear from your code. The main problem is when a type needs to return a pointer to itself, but in my own code, I've found that need to be rare (if anything, I'm more likely to pass an object out of its own member function by &, not by pointer). The primary counter-example is when a class that it owns needs to have access to it, but then in most cases, that class doesn't need to pass that pointer on to anyone else, and since it lives for as long as its parent does, it doesn't have to worry about ref-counting. I suppose that using & would work just as well in those cases, though I don't tend to use & much outside of passing into a function and returning out of it (generally when having a copy is okay but I want it to be possible to avoid it), because it's too easy to make inadvertent copies.
Having ref-counting built into the type does solve some of those problems, but it can cause others. I doubt that there was ever any chance that the C++ standards committee would have ever gone with built-in ref-counting though given how invasive that is in the class hierarchy and how it would not work very well with existing code. In our case, with classes, built-in ref-counting like DIP 74 proposes is probably better.
- Jonathan M Davis
