Would you pay for GC?

norm norm.rowtree at gmail.com
Wed Jan 26 03:25:51 UTC 2022


On Tuesday, 25 January 2022 at 08:24:22 UTC, rikki cattermole 
wrote:
>
> On 25/01/2022 8:22 PM, Elronnd wrote:
>> On Tuesday, 25 January 2022 at 07:13:41 UTC, Paulo Pinto wrote:
>>> ARC will also not compete, unless one goes the extra mile of 
>>> making the compiler ARC aware, elide retain/release calls, do 
>>> cascade deletions in background threads, take care on cascade 
>>> deletions to avoid stack overflows on destructor calls, 
>>> provide multicore friendly versions of them,.....
>> 
>> Indeed.  See Bacon et al, 'Unified Theory of Garbage 
>> Collection': increasingly sophisticated RC approaches tracing 
>> (and vice versa).  So it's a bit strange to assume we can do 
>> one but not the other.  And tracing makes a better starting 
>> point due to the generational hypothesis.
>
> RC shines for when deterministic destruction is required.

In a small code base it might but in larger SW RC is on par with 
GC because it is impossible to keep track of all the references. 
You end up with leaks and dangling shared_ptrs because someone 
has a ref ... somewhere.

The best option in a large code base is RAII with value types 
until you cannot and then rely on unique_ptr equivalents that can 
only have a single owner at any one time (without hackery). Only 
RC/shared_ptr when you absolutely must have multiple owners and 
even then interrogate your design.


More information about the Digitalmars-d mailing list