Smart pointers instead of GC?

[deadalnix]

On Tuesday, 4 February 2014 at 20:16:20 UTC, Steven Schveighoffer 
wrote:
> On Tue, 04 Feb 2014 15:10:48 -0500, deadalnix 
> <deadalnix at gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 19:28:08 UTC, Steven 
>> Schveighoffer wrote:
>>> Where you have to be cognizant is avoiding cycles. Plain and 
>>> simple. And it's not that difficult. The compiler takes care 
>>> of the rest. It's somewhat magical I suppose :) Managing your 
>>> autorelease pools can make a difference, but is not 
>>> necessarily critical.
>>>
>>
>> My experience is that, just like null reference, it is highly 
>> dependent on the type of code you are facing.
>>
>> Typically, you'll have trouble with complex graph of objects.
>
> This is very true. I have only dealt with acyclic (except for 
> parent pointers) graphs or linked-lists.
>
> For specialized cases, you will have to NULL out the pointers 
> to/from a node that has to be deleted (essentially a manual 
> delete).
>
> But it works VERY well for linked-lists/queues. My app is I/O 
> intensive, so I have a lot of that.
>
> -Steve

Yes.

Also, another issue comes up when you share data across threads.

Core can share a cache line in read mode, but can't in write 
mode. That mean that updating the reference count will cause 
contention on the cache line (core will have to fight for the 
cache line ownership). That is why immutability + GC is so 
efficient in a highly concurrent system, and ref counting would 
ruin that.