John Carmack applauds D's pure attribute

[Martin Nowak]

On Mon, 27 Feb 2012 09:32:27 +0100, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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.
>
Yeah, I used the pointer for the deleter in the unshared case.
Assuming that the allocator interface will require a delegate
callback and not a function it might make more sense to directly
stuff it onto the heap.
There is one caveat with make_shared, weak_ptrs will keep your object
alive because they need the control block. One could do a realloc though.

>>
>> 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.

I hope I did that. Or do you mean when holding a class. I think it's needed
for classes because of the monitor, not sure though.