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.
Shared_ptr and unique_ptr represent ownership, not references. So
you should not pass them around unless you transfer ownership.
When the owner allows someone to borrow a reference, that
borrowing point has to ensure that the reference does not outlive
the lifespan of the object. This is not so hard to get right.
shared_ptr has several advantages:
1. It works with existing classes (from foreign libraries)
without any notion of RC.
2. It allows weak references and cycles without keeping the whole
object allocated.
3. It supports concurrency.
5. The reference counting mechanism can be done in a way that
fits with polymorphism since it does not make any assumptions
about the structure of object itself.
6. The object itself can remain fully immutable.
Disadvantages:
1. double indirection
2. two allocations
