I see. I agree clear() is definitely safer in these situations. But if the constructor gets called again automatically after clear(), that would mean the other references could still use the object since it's in a valid state again, right?<br>
<br><div class="gmail_quote">On Tue, Aug 10, 2010 at 2:25 PM, Steven Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Mon, 09 Aug 2010 20:07:28 -0400, Andrej Mitrovic <<a href="mailto:andrej.mitrovich@gmail.com" target="_blank">andrej.mitrovich@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I don't have a lot of experience in this field, but my guess is people want<br>
to help out the GC be more efficient in some regard.<br>
<br>
"Hey, GC! I know you take the trash out every day, but I just want to let<br>
you know that I've cleaned up my room and there's a whole bag o' dirt in<br>
here ready to be thrown out that you should know about. See ya later!"<br>
<br>
My assumption is that the programmer probably knows when and how he uses<br>
memory more so than the GC itself. So my thinking is some kind of hybrid<br>
approach would be a good choice between safety and performance here. But<br>
correct me if I'm wrong, I'm walking in the dark really..<br>
<br>
</blockquote>
<br></div>
That is delete. Here is the problem:<br>
<br>
class C {<br>
int x;<br>
}<br>
<br>
void main()<br>
{<br>
auto c = new C;<br>
c.x = 1;<br>
auto c2 = c;<br>
delete c;<br>
assert(c is null);<br>
assert(c2 !is null);<br>
c2.x = 5; // oops! I just wrote to unallocated memory.<br>
auto c3 = new C; // might occupy space just freed<br>
c2.x = 5; // double oops! I may have just overwritten c3<br>
}<br>
<br>
compare this to clear. If clear leaves the memory around until there are no references, then referring to that memory does not corrupt other unrelated parts of the code. Memory corruption is the granddaddy of all horrible bugs, because the cause is usually a) long gone by the time you see any symptoms, b) can be completely decoupled from the symptom, and c) can cause *random* symptoms. If D can avoid memory corruption, and it costs very little, it should do so.<br>
<br>
The thing is, even with clear, the above code is undefined -- a cleared object is in no state to be used. But the difference between delete and clear is -- delete ensures the reference you delete will cause an immediate error on use, but does nothing to prevent memory corruption to all the other references to the same memory. Clear does the same for the reference you clear, but also prevents memory corruption for all the other references to the same memory. So even though you are in undefined territory, the runtime makes a best effort to avoid you cutting off your head. The error may still be silent, but it's not deadly.<br>
<br>
It might even be a good idea to zero out the vtable to cause a loud error on the next dynamic cast or virtual function call :)<br>
<br>
-Steve<br>
</blockquote></div><br>