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

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 15 23:52:40 PDT 2014


On Tuesday, 15 July 2014 at 21:11:24 UTC, John Colvin wrote:
> On Tuesday, 15 July 2014 at 20:03:15 UTC, Chris wrote:
>> On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via 
>> Digitalmars-d wrote:
>>> On Mon, Jul 14, 2014 at 11:22:53PM +0000, John Carter via 
>>> Digitalmars-d wrote:
>>> [...]
>>>> Any other good blog posts / social media comments / pointers 
>>>> I can
>>>> digest and use?
>>>
>>> This one came to mind:
>>>
>>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>>>
>>>
>>
>> From the link above:
>>
>> "It’s a common but false belief that reference counting (using 
>> shared pointers in particular) is better than garbage 
>> collection. There is actual research* showing that the two 
>> approaches are just two sides of the same coin. You should 
>> realize that deleting a shared pointer may lead to an 
>> arbitrary long pause in program execution, with similar 
>> performance characteristics as a garbage sweep. It’s not only 
>> because every serious reference counting algorithm must be 
>> able to deal with cycles, but also because every time a 
>> reference count goes to zero on a piece of data a whole graph 
>> of pointers reachable from that object has to be traversed. A 
>> data structure built with shared pointers might take a long 
>> time to delete and, except for simple cases, you’ll never know 
>> which shared pointer will go out of scope last and trigger it."
>>
>> * http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
>
> I've been wondering about this. Could the following argument be 
> true?
>
> Situations where automatic memory management are necessary are, 
> by definition, the situations where one cannot easily reason 
> about where memory freeing can occur. Therefore, no automatic 
> memory management system can be considered practically 
> predictable, unless you didn't* need it in the first place.
>
> *strictly speaking

Which happens all the time in any codebase written by more than 
one developer.

Developer attrition and third party libraries help to the entropy 
of memory leak bugs.

Personally, I don't believe anyone is able to reason properly 
about manual memory management, unless they wrote 100% of their 
code, and don't work in more than one codebase.

--
Paulo


More information about the Digitalmars-d mailing list