• Angus Graham (11/11) Aug 16 2001 I imagine that if you explicitly delete an object while there are still
• Walter (9/20) Aug 16 2001 type
• Sheldon Simms (19/47) Aug 17 2001 I wanted to bring this up too yesterday. I really don't understand how
• Angus Graham (16/28) Aug 17 2001 I can think of many cases where delete would be useful:
• Sean L. Palmer (17/46) Oct 23 2001 I really don't grok well with GC, I've grown so accustomed to the C++ wa...
• Angus Graham (10/15) Aug 17 2001 Let me rephrase the question:
• Walter (4/11) Aug 18 2001 Nothing really, just the time spent.
• Sean L. Palmer (6/17) Oct 23 2001 This sounds like what I just said... just 2 months earlier. ;) Sorry.
• Sheldon Simms (6/19) Aug 19 2001 Which is basically exactly what I suggested, except that in my version

"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

"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

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


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.

"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

 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

 
 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

"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

"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?

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

"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

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

"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


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


 Yes, that is possible.

"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