I don't have a lot of experience in this field, but my guess is people want 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 you know that I've cleaned up my room and there's a whole bag o' dirt in 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 memory more so than the GC itself. So my thinking is some kind of hybrid approach would be a good choice between safety and performance here. But correct me if I'm wrong, I'm walking in the dark really..<br>
<br><div class="gmail_quote">On Tue, Aug 10, 2010 at 1:57 AM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisprog@gmail.com">jmdavisprog@gmail.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 Monday, August 09, 2010 16:40:23 Andrei Alexandrescu wrote:<br>
> class File {<br>
> FILE * fp;<br>
> this() { fp = fopen("/tmp/temporary"); }<br>
> ~this() { fclose(fp); }<br>
> }<br>
><br>
> The destructor does not test fp because it assumes it was opened.<br>
><br>
> Interestingly enough, by TDPL the code above is in fact invalid already.<br>
> TDPL mentions that an object's lifetime starts as soon as it's been<br>
> branded, which is before default construction. As a direct consequence,<br>
> the destructor should be able to deal with an object stamped with all<br>
> init values for all fields - in this case a null fp.<br>
<br>
</div>I would take that as an argument for making clear() set the object in the state<br>
prior to the constructor call. That state is supposed to be completely valid<br>
from a memory standpoint. True, it goes against class invariants, but it would<br>
make clear() function in a manner closer to the delete that some folks are<br>
looking for. Truth be told, I'd sooner argue for removing clear() entirely,<br>
forcing people to either call a specific method on the class in question to free<br>
up whatever resources that they're so interested in freeing up, or forcing them<br>
to just give up on trying to free them and let the garbage collector do its<br>
thing. But if there's enough demand for a function which destroys an object and<br>
puts it in some sort of state which won't have undefined behavior, then making<br>
clear() put the class in a pre-constructor state seems the best to me. It's at<br>
least closer to what the folks who want delete are looking for. Of course, they<br>
probably won't be entirely happy until they have the nuke() function that you<br>
mentioned earlier, but at some point you have to face the fact that you're<br>
dealing with a garbage collected langugage and let it do its thing unless you<br>
really need to manually manage memory (at which point you should manually manage<br>
memory rather than try to contort the garbage collector).<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>