John Carmack applauds D's pure attribute

Timon Gehr timon.gehr at
Mon Feb 27 00:32:27 PST 2012

On 02/27/2012 02:29 AM, Martin Nowak wrote:
> On Sun, 26 Feb 2012 20:26:41 +0100, Walter Bright
> <newshound2 at> wrote:
>> On 2/26/2012 7:04 AM, Simon wrote:
>>> On 26/02/2012 03:22, Walter Bright wrote:
>>>> On 2/25/2012 4:01 PM, Simon wrote:
>>>>> On 25/02/2012 22:55, Walter Bright wrote:
>>>>>> Enter C++'s shared_ptr. But that works by, for each object,
>>>>>> allocating a
>>>>>> *second* chunk of memory to hold the reference count. Right off
>>>>>> the bat,
>>>>>> you've got twice as many allocations & frees with shared_ptr than
>>>>>> a GC
>>>>>> would have.
>>>>> so you don't have to have twice as many allocations.
>>>> There are many ways to do shared pointers, including one where the
>>>> reference count is part of the object being allocated. But the C++11
>>>> standard share_ptr does an extra allocation.
>>> The stl one is based on boost, so it has make_shared as well:
>>> and it's in vs 2010
>>> Not that I'm claiming shared pointers are superior to GC.
>> At the GoingNative C++ conference, the guy who is in charge of STL for
>> VS said that it did an extra allocation for the reference count.
> It's actually quite nice to combine unique_ptr and shared_ptr.
> One can lazily create the refcount only when the pointers are shared.
> Often one can get away with unique ownership.

Ok. Btw, if the utility is in charge of allocation, then the refcount 
can be allocated together with the storage.


Neat. Possible improvement (if I understand your code correctly): Don't 
add the GC range if all possible aliasing is through Ptr.

More information about the Digitalmars-d mailing list