Smart pointers instead of GC?

Steven Schveighoffer schveiguy at yahoo.com
Tue Feb 4 14:46:24 PST 2014


On Tue, 04 Feb 2014 17:27:46 -0500, Paulo Pinto <pjmlp at progtools.org>  
wrote:

> Am 04.02.2014 23:17, schrieb Steven Schveighoffer:
>> On Tue, 04 Feb 2014 16:37:20 -0500, Ola Fosheim Grøstad
>> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>>
>>> If you blindly use ARC rather than sane RC. There is no reason to up
>>> the ref count if the data structure is "owned" while processing it.
>>> Which is a good reason to avoid ARC and use regular RC. If you know
>>> that the entire graph has a 1+ count, you don't need to do any ref
>>> counting while processing it.
>>
>> This is an important point. However, the default is to be safe, and good
>> enough for most. As long as there is a way to go into "I know what I'm
>> doing" mode for encapsulated low-level code, the default should be to do
>> ARC. ARC should handle simple cases, like if the reference only ever
>> exists as a stack local.
>>
>> One could also say you could mark a memory region as no-scan if you know
>> that the data it points at will never be collected for its entire
>> existence in a GC environment.
>>
>> I think some mix of GC and ref counting for D would be extremely useful.
>>
>> In my major Objective C project, I use manual reference counting, and I
>> do avoid extra retains for redundant pointers. I've also had a few bugs
>> because of that :)
>
> How big is your team?

2

> Based on my experience, this type of coding falls apart in the typical  
> corporate team size.

It's not clear what "this type of coding" refers to, but I'll assume you  
targeted the last paragraph.

If it's encapsulated (and it is), it should be relatively untouched. In  
fact, I haven't touched the linked list part of it for a long time.

Note that the MRC was not really our choice, the project existed before  
ARC did.

-Steve


More information about the Digitalmars-d mailing list