Eliminate class allocators and deallocators?

Leandro Lucarella llucax at gmail.com
Tue Oct 6 19:44:05 PDT 2009


Andrei Alexandrescu, el  6 de octubre a las 21:36 me escribiste:
> >I don't think it is a good idea (GC-wise) to say that in the specs.
> >I think the GC implementor should be free to decide if a delete really
> >free the memory or not. Some collectors can do this very naturally (like
> >the current one) and some others don't (like allocators that uses
> >pointer-bump allocation). I think the language should divide destruction
> >and deallocation, but I don't think is a good idea not to notify the GC at
> >all when delete is used. I think the GC should be able to do whatever it
> >feels is good for him (so the user should not rely either on the memory
> >being actually freed or otherwise).
> >
> 
> I agree insofar as a GC could be tipped by the compiler that no live
> reference of the object exists after delete.

Great! For example, this would let me protect the object pages (if it's
a large object that uses one or more full pages) when they are freed so
the program segfaults as soon as a deleted object is used when it
shouldn't. That could be a nice debugging feature :)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, with you ear against the wall
Waiting for someone to call out
Would you touch me?



More information about the Digitalmars-d mailing list