TDPL: Manual invocation of destructor

[Andrej Mitrovic]

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.

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

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

On Tue, Aug 10, 2010 at 1:57 AM, Jonathan M Davis <jmdavisprog at gmail.com>wrote:

> On Monday, August 09, 2010 16:40:23 Andrei Alexandrescu wrote:
> > class File {
> >      FILE * fp;
> >      this() { fp = fopen("/tmp/temporary"); }
> >      ~this() { fclose(fp); }
> > }
> >
> > The destructor does not test fp because it assumes it was opened.
> >
> > Interestingly enough, by TDPL the code above is in fact invalid already.
> > TDPL mentions that an object's lifetime starts as soon as it's been
> > branded, which is before default construction. As a direct consequence,
> > the destructor should be able to deal with an object stamped with all
> > init values for all fields - in this case a null fp.
>
> I would take that as an argument for making clear() set the object in the
> state
> prior to the constructor call. That state is supposed to be completely
> valid
> from a memory standpoint. True, it goes against class invariants, but it
> would
> make clear() function in a manner closer to the delete that some folks are
> looking for. Truth be told, I'd sooner argue for removing clear() entirely,
> forcing people to either call a specific method on the class in question to
> free
> up whatever resources that they're so interested in freeing up, or forcing
> them
> to just give up on trying to free them and let the garbage collector do its
> thing. But if there's enough demand for a function which destroys an object
> and
> puts it in some sort of state which won't have undefined behavior, then
> making
> clear() put the class in a pre-constructor state seems the best to me. It's
> at
> least closer to what the folks who want delete are looking for. Of course,
> they
> probably won't be entirely happy until they have the nuke() function that
> you
> mentioned earlier, but at some point you have to face the fact that you're
> dealing with a garbage collected langugage and let it do its thing unless
> you
> really need to manually manage memory (at which point you should manually
> manage
> memory rather than try to contort the garbage collector).
>
> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100810/c7a548cd/attachment.html>