Why same pointer type for GC and manual memory?

IGotD- nise at nise.com
Fri Nov 15 10:55:55 UTC 2019


On Friday, 15 November 2019 at 08:58:43 UTC, user1234 wrote:
> On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
>> I'm trying to find the rationale why GC pointers (should be 
>> names managed pointers) are using the exact same type as any 
>> other pointer.
>>
>> Doesn't this limit the ability to change the default GC type?
>> Doesn't this confusion make GC pointers just as unsafe as raw 
>> pointers?
>> Has there been any prior discussion about introducing managed 
>> pointers in D?
>
> One other reason is that special pointers are not good for 
> debugging and have a runtime cost... in D it's not like in a VM.

It's true it has a runtime cost but I'm wondering if it isn't 
worth it. There will be an extra dereference of course but this 
is only done once per for every piece that use the fat pointer.

With a fat pointer you could also provide more information, 
allocated size for example which makes it possible to safely cast 
the pointer to anything checking that the boundaries are correct. 
Also reading a fat pointer (like *ptr) can check the bounds. Size 
information is also handy for some allocators, buddy allocator 
for example where storing the size in the allocated block is 
something that you not always want to as it throws the memory off 
the natural alignment which is one of the benefits of the buddy 
allocator. In the fat pointer you could store more information 
like reference count, type of allocator, a pointer to free 
function (makes it possible to hotswap allocators).

When it comes to debugging, then you need to parse the fat 
pointer, just like it parses common containers classes. This is 
not a too big deal I think.



More information about the Digitalmars-d-learn mailing list