LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

[Araq via Digitalmars-d]

On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Jul 16, 2014 at 06:11:54PM +0000, Araq via 
> Digitalmars-d wrote:
>> On Wednesday, 16 July 2014 at 16:57:18 UTC, Kagamin wrote:
>> >On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via 
>> >Digitalmars-d
>> >wrote:
>> >>Not to mention, when you need to deallocate a large complex 
>> >>data
>> >>structure, *somebody* has to do the work -- either you do it
>> >>yourself, or the reference counting implementation, or the 
>> >>GC.
>> >
>> >The first and the last options are still prominent.
>> 
>> A copying GC copies the live data, deallocation of a large 
>> complex
>> data structure is free in this scenario. Same if you use a 
>> manually
>> managed memory region for the data structure and then 
>> deallocate the
>> region via some batch operation. But hey, this simple fact 
>> must be
>> wrong because some guy read a single paper about GCs that 
>> doesn't even
>> cover this point.
>
> Have you even read the paper? What you just said is exactly 
> what the
> paper is describing. There are two ends of the spectrum of 
> memory
> reclamation algorithms, at one end, you're tracing "matter" 
> (live
> objects), and the other end you're tracing "antimatter" (dead 
> objects).
> They are just duals of each other, and optimized GC/RC 
> algorithms tend
> to approach the middle ground, with time/memory tradeoffs as an
> adjustable parameter.

The paper focusses on RC vs "tracing". My point is "tracing" vs 
"copying" is another tradeoff. Here is a mark&sweep algorithm:

- Trace live objects.
- For each dead object: Deallocate.

Here is a copying GC:

- Trace and copy live objects.
- There is no deallocation step. The old region is free for 
further usage.