John Carmack applauds D's pure attribute

[Timon Gehr]

On 02/27/2012 02:29 AM, Martin Nowak wrote:
> On Sun, 26 Feb 2012 20:26:41 +0100, Walter Bright
> <newshound2 at digitalmars.com> 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.
>>>>>
>>>>> http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/make_shared.html
>>>>>
>>>>> 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:
>>>
>>> http://en.cppreference.com/w/cpp/memory/shared_ptr
>>>
>>> and it's in vs 2010
>>>
>>> http://msdn.microsoft.com/en-us/library/ee410595.aspx
>>>
>>> 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.

>
> https://gist.github.com/1920202

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