www.digitalmars.com         C & C++   DMDScript  

D - delete - questions/suggestions

reply "Angus Graham" <agraham_d agraham.ca> writes:
I imagine that if you explicitly delete an object while there are still
pointers too it, D would not complain.  After all you may never actually
_use_ that pointer again.

But what happens if you do use it?  What if another object of the same type
now resides in that memory?

Do you have the option to generate a runtime error on use of a pointer to
deleted object?  How about on deletion of an object with pointers to it?

Does deleting an object automatically null out the pointer?  Alternatively,
could you do this:

delete theThing = null;


Angus Graham
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Angus Graham" <agraham_d agraham.ca> wrote in message
news:9lh6au$2qu7$1 digitaldaemon.com...
 I imagine that if you explicitly delete an object while there are still
 pointers too it, D would not complain.  After all you may never actually
 _use_ that pointer again.

 But what happens if you do use it?  What if another object of the same

 now resides in that memory?

 Do you have the option to generate a runtime error on use of a pointer to
 deleted object?  How about on deletion of an object with pointers to it?

 Does deleting an object automatically null out the pointer?

 could you do this:

 delete theThing = null;


 Angus Graham

Deleting a pointer (or reference) will automatically null out the pointer (or reference). However, if you still have a dangling pointer to it elsewhere, that pointer will now point to garbage. I don't know how to eliminate this problem. This means that operatore delete is more of an optimization thing than a core feature.
Aug 16 2001
next sibling parent reply "Sheldon Simms" <sheldon semanticedge.com> writes:
Im Artikel <9lhqrm$dac$1 digitaldaemon.com> schrieb "Walter"
<walter digitalmars.com>:

 "Angus Graham" <agraham_d agraham.ca> wrote in message
 news:9lh6au$2qu7$1 digitaldaemon.com...
 I imagine that if you explicitly delete an object while there are still
 pointers too it, D would not complain.  After all you may never
 actually _use_ that pointer again.

 But what happens if you do use it?  What if another object of the same

 now resides in that memory?

 Do you have the option to generate a runtime error on use of a pointer
 to deleted object?  How about on deletion of an object with pointers to
 it?

 Does deleting an object automatically null out the pointer?

 could you do this:

 delete theThing = null;


 Angus Graham

Deleting a pointer (or reference) will automatically null out the pointer (or reference). However, if you still have a dangling pointer to it elsewhere, that pointer will now point to garbage. I don't know how to eliminate this problem. This means that operatore delete is more of an optimization thing than a core feature.

I wanted to bring this up too yesterday. I really don't understand how the delete operator is useful at all. The doc seems to say that the object will be immediately garbage collected, but it is very possible that there are other references to the object. If so, you might as well just change the keyword to "bug" or "crash". The only somewhat useful semantics I could think of for delete would be something like "please check and see if this can be garbage collected". IOW, it would be a way to have a little control over GC. When I think there is time to do some GC work (maybe when waiting for input), I can explicitly delete stuff I don't want anymore. This would simply instruct the GC to see IF these things can be collected. If they can't be GC'd then nothing happens. If they can be GC'd then they are. Then again, with this semantics, delete becomes somewhat like "register" in C - an advisory that can be ignored. Maybe there's just no good reason for a delete operator... -- Sheldon Simms / sheldon semanticedge.com
Aug 17 2001
next sibling parent "Angus Graham" <agraham_d agraham.ca> writes:
"Sheldon Simms" <sheldon semanticedge.com> wrote >

 I wanted to bring this up too yesterday. I really don't understand how
 the delete operator is useful at all. The doc seems to say that the
 object will be immediately garbage collected, but it is very possible
 that there are other references to the object. If so, you might as well
 just change the keyword to "bug" or "crash".

 The only somewhat useful semantics I could think of for delete would be
 something like "please check and see if this can be garbage collected".
 IOW, it would be a way to have a little control over GC. When I think
 there is time to do some GC work (maybe when waiting for input), I can
 explicitly delete stuff I don't want anymore. This would simply instruct
 the GC to see IF these things can be collected. If they can't be GC'd
 then nothing happens. If they can be GC'd then they are.

I can think of many cases where delete would be useful: You have a loop which allocates tons of temporary things. For better locality, you would want to delete each one as soon as you're finished with it so the next can be allocated in it's place. Systems without VM where keeping memory tightly packed is important. Memory isn't the only resource an object can own. It could own network connections, plutonium rods, whatever. If the resource is limited you need to explicitly be able to release it so you have a guarantee that you can get more. The CG system would have no idea when it's time to free up some more plutonium, so manual management is the only answer for these objects. If I have pointers to an object who's lifetime is in doubt that's a bug. Whether the program crashes or not, it's a bug. Personally I think a crash is the best thing that could happen in that case (the alternative being a program that appears to work, but only by blind luck). Angus Graham
Aug 17 2001
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
I really don't grok well with GC, I've grown so accustomed to the C++ way of
doing things (reference counting).  Sometimes it's nice to separate the
concept of destruction from deallocation, sometimes I wish they were always
together, unified.

I guess I like the D way which is that usually you let the GC handle it,
however if your code *knows* that nobody else is using an object or other
memory, it can use the delete operation to notify the GC about it.

Maybe in Debug builds, a call to delete obj, where obj was an object that
still has outstanding references elsewhere, could cause the GC to throw an
exception.  It could search for usages and only if there are none would it
allow the deletion.  In Release builds, it would likely assume there are no
other uses to speed the GC, at the risk of bugs or crashes.

I suppose calling a dtor manually would be nice for writing container
classes, but in some cases you can live with dtors happening "at some
unspecified point in the future" when the GC gets around to it, and
sometimes you want the thing shut down pronto.

Sean

 Does deleting an object automatically null out the pointer?

 could you do this:

 delete theThing = null;


 Angus Graham

Deleting a pointer (or reference) will automatically null out the pointer (or reference). However, if you still have a dangling pointer to it elsewhere, that pointer will now point to garbage. I don't know how to eliminate this problem. This means that operatore delete is more of an optimization thing than a core feature.

I wanted to bring this up too yesterday. I really don't understand how the delete operator is useful at all. The doc seems to say that the object will be immediately garbage collected, but it is very possible that there are other references to the object. If so, you might as well just change the keyword to "bug" or "crash". The only somewhat useful semantics I could think of for delete would be something like "please check and see if this can be garbage collected". IOW, it would be a way to have a little control over GC. When I think there is time to do some GC work (maybe when waiting for input), I can explicitly delete stuff I don't want anymore. This would simply instruct the GC to see IF these things can be collected. If they can't be GC'd then nothing happens. If they can be GC'd then they are. Then again, with this semantics, delete becomes somewhat like "register" in C - an advisory that can be ignored. Maybe there's just no good reason for a delete operator...

Oct 23 2001
prev sibling parent reply "Angus Graham" <agraham_d agraham.ca> writes:
"Walter" <walter digitalmars.com>

 Deleting a pointer (or reference) will automatically null out the pointer
 (or reference). However, if you still have a dangling pointer to it
 elsewhere, that pointer will now point to garbage. I don't know how to
 eliminate this problem. This means that operatore delete is more of an
 optimization thing than a core feature.

Let me rephrase the question: The GC system has a list of pointers to objects right? So when I delete an object, what prevents the GC system from scanning the pointers and if it finds a pointer to the deleted object, boom! Runtime error! You could turn this feature on and off by command line or pragma, thus you could debug with slow-and-safe-deletes and release with quick-and-dangerous-deletes. Angus Graham
Aug 17 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Angus Graham wrote in message <9ljspv$27da$1 digitaldaemon.com>...
The GC system has a list of pointers to objects right?

No, it usually scans the memory space for pointers to objects.
So when I delete an object, what prevents the GC system from scanning the
pointers and if it finds a pointer to the deleted object, boom!  Runtime
error!

Nothing really, just the time spent.
You could turn this feature on and off by command line or pragma, thus you
could debug with slow-and-safe-deletes and release with
quick-and-dangerous-deletes.

Yes, that is possible.
Aug 18 2001
parent "Sean L. Palmer" <spalmer iname.com> writes:
This sounds like what I just said... just 2 months earlier.  ;)  Sorry.
Would be a great feature though.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:9lnhga$1h9q$1 digitaldaemon.com...
 Angus Graham wrote in message <9ljspv$27da$1 digitaldaemon.com>...
The GC system has a list of pointers to objects right?

No, it usually scans the memory space for pointers to objects.
So when I delete an object, what prevents the GC system from scanning the
pointers and if it finds a pointer to the deleted object, boom!  Runtime
error!

Nothing really, just the time spent.
You could turn this feature on and off by command line or pragma, thus


could debug with slow-and-safe-deletes and release with
quick-and-dangerous-deletes.

Yes, that is possible.

Oct 23 2001
prev sibling parent "Sheldon Simms" <sheldon semanticedge.com> writes:
Im Artikel <9ljspv$27da$1 digitaldaemon.com> schrieb "Angus Graham"
<agraham_d agraham.ca>:

 "Walter" <walter digitalmars.com>
 
 Deleting a pointer (or reference) will automatically null out the
 pointer (or reference). However, if you still have a dangling pointer
 to it elsewhere, that pointer will now point to garbage. I don't know
 how to eliminate this problem. This means that operatore delete is more
 of an optimization thing than a core feature.

Let me rephrase the question: The GC system has a list of pointers to objects right? So when I delete an object, what prevents the GC system from scanning the pointers and if it finds a pointer to the deleted object, boom! Runtime error!

Which is basically exactly what I suggested, except that in my version there wouldn't be a crash, the object just wouldn't be deleted. -- Sheldon Simms / sheldon semanticedge.com
Aug 19 2001