DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

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