www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Destructor Bug?

reply AJG <AJG_member pathlink.com> writes:
Hi,

I took me a while to find and reduce this to a minimal example. I was going nuts
thinking it was my database abstraction layer. I think it's a bug in D.

# // test.d 
# class Test {
#     Object obj = null;
#     this () { obj = new Object(); }
#     ~this() { obj.toString();     }
# }
#
# void main() { new Test(); }

Segmentation Fault w/ DMD 0.128 on linux.

Cheers,
--AJG.
Jul 30 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 I took me a while to find and reduce this to a minimal example. I was  
 going nuts
 thinking it was my database abstraction layer. I think it's a bug in D.

 # // test.d
 # class Test {
 #     Object obj = null;
 #     this () { obj = new Object(); }
 #     ~this() { obj.toString();     }
 # }
 #
 # void main() { new Test(); }

 Segmentation Fault w/ DMD 0.128 on linux.

http://www.digitalmars.com/d/class.html#destructors "When the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references are no longer valid. This means that destructors cannot reference sub objects." So this is documented and correct behaviour. Ciao uwe
Jul 31 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,

http://www.digitalmars.com/d/class.html#destructors
"When the garbage collector calls a destructor for an object of a class  
that has members that are references to garbage collected objects, those  
references are no longer valid. This means that destructors cannot  
reference sub objects."

So this is documented and correct behaviour.

Is there any way around this? I'd like to close a database connection upon destruction, but this won't let me. In addition, what's the point of a destructor that's can't access sub-objects? How would you do clean-up operations that are not strictly memory-related? Like clearing a mutex, or releasing a lock on a shared resource (such as a hardware device), or performing database finalization (closing connections, committing changes, etc.)? Is there a preferred way of doing that right now? Thanks for the help! --AJG.
Jul 31 2005
next sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Is there any way around this? I'd like to close a database connection  
 upon destruction, but this won't let me.

I had a similar problem when implementing signals&slots. You can create the sub-object on the C heap with malloc(). Or close the connection in the sub-object's destructor. This problem can happen if there are difficult relations between objects, but mostly it shows imperfect design, i think. If a class owns a child, and it has to call finalization routines of it when being destructed, that somehow means that the child does not fully take care of its own destruction, right? So it does not fully protect its invariant. Either that should be changed, or if that is not possible a sub-struct should be used, and the parent class takes care of protecting the invariant. Ciao uwe
Jul 31 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

 Is there any way around this? I'd like to close a database connection  
 upon destruction, but this won't let me.

I had a similar problem when implementing signals&slots. You can create the sub-object on the C heap with malloc(). Or close the connection in the sub-object's destructor.

Hm... maybe this could work. What's the equivalent code using malloc? I mean, how do you call the object's constructor(s) using this method?
This problem can happen if there are difficult relations between objects,  
but mostly it shows imperfect design, i think. If a class owns a child,  
and it has to call finalization routines of it when being destructed, that  
somehow means that the child does not fully take care of its own  
destruction, right? So it does not fully protect its invariant. Either  
that should be changed, or if that is not possible a sub-struct should be  
used, and the parent class takes care of protecting the invariant.

It very well might be a problem in one class' design. However, just because this is the case, doesn't mean we shouldn't be allowed to do it. We should be allowed, precisely to fix this kind of problem when the code is not ours. What about legacy code and libraries? Sometimes these things don't follow ideal OO design, and as it stands, we can't properly fix it in the destructor. In addition, what about when clean-up isn't that simple? What if there are options that need to be specified? As a trivial example, you could have: void DB::close(bool commit) { if (commit) m_Conn.commit(); m_Conn.close(); } Sure, you could move those parameters to the constructor as AutoCommit, but why move finalization logic to the constructor? IMO that's why we have destructors, to fully take care of cleanup for objects that don't do it easily and automatically. Thanks for the help, --AJG.
Jul 31 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 Hm... maybe this could work. What's the equivalent code using malloc? I  
 mean, how do you call the object's constructor(s) using this method?

Hmm, as it is legacy code, i fear that it is not possible. You can look into http://www.digitalmars.com/techtips/class_objects.html But this is more like a hack. The correct way would be to overload operator new and delete for the class. See http://www.digitalmars.com/d/memory.html#newdelete And you are right, in this case there is really a need for the destructor to access sub-objects. Anyways, imagine two objects that are "linked together": class A { B b; } class B { A a; } One of them has to be deleted first. Which one, that is undetermined. Thus you cannot be sure to be able to access b in A's destructor and vice versa. The GC would have to examine this kind of relationships, and they could be much more complex. That's the reason for the current rule. Another solution, by the way: use delete on your object. In this case you *can* reference sub-objects. Ciao uwe
Aug 01 2005
prev sibling next sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
To answer your other question fully:

 In addition, what's the point of a destructor that's can't access  
 sub-objects?

It would make the job of the garbage collector more difficult, i guess.
 How would you do clean-up operations that are not strictly  
 memory-related? Like
 clearing a mutex, or releasing a lock on a shared resource (such as a  
 hardware
 device), or performing database finalization (closing connections,  
 committing changes, etc.)?

I can only think of the following solutions: * Allocate the objects somewhere else than the GC heap. * Use structs. This is somehow similar to the next one: * Change the design. Example: a file object could have a "autoClose" property that is set to true by the parent if necessary, and the file destructor automatically closes the attached handle in this case. The third one should be the preferred, of course. Ciao uwe
Jul 31 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,

To answer your other question fully:

 In addition, what's the point of a destructor that's can't access  
 sub-objects?

It would make the job of the garbage collector more difficult, i guess.

I wonder whether it makes it trivially more difficult or not. It could also be that Walter specifially doesn't want that kind of behaviour in the destructor (for philosophical reasons, a la opAssign). Although that would just be mean. ;) If I'm not mistaken both C++ and C# allow for sub-object references in the destructor, right?
 How would you do clean-up operations that are not strictly  
 memory-related? Like
 clearing a mutex, or releasing a lock on a shared resource (such as a  
 hardware
 device), or performing database finalization (closing connections,  
 committing changes, etc.)?

I can only think of the following solutions: * Allocate the objects somewhere else than the GC heap.

Yeah, this could be an option. I posted a question about this on the other message.
* Use structs. This is somehow similar to the next one:
* Change the design. Example: a file object could have a "autoClose"  
property that is set to true by the parent if necessary, and the file  
destructor automatically closes the attached handle in this case.
The third one should be the preferred, of course.

Unfortunately, I can't do such a thing because it's not my code. Thanks for the help, --AJG.
Jul 31 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dcj0gn$c7r$1 digitaldaemon.com>, AJG says...
Hi,

http://www.digitalmars.com/d/class.html#destructors
"When the garbage collector calls a destructor for an object of a class  
that has members that are references to garbage collected objects, those  
references are no longer valid. This means that destructors cannot  
reference sub objects."

So this is documented and correct behaviour.

Is there any way around this? I'd like to close a database connection upon destruction, but this won't let me. In addition, what's the point of a destructor that's can't access sub-objects? How would you do clean-up operations that are not strictly memory-related? Like clearing a mutex, or releasing a lock on a shared resource (such as a hardware device), or performing database finalization (closing connections, committing changes, etc.)? Is there a preferred way of doing that right now? Thanks for the help! --AJG.

Would something like this cause a complete re-write for you? #class DBConn #{ # this() { ... } # ~this() { close(); } # void open() { ... } # void close() { ... } #} #class Test #{ # DBConn obj; # this () { obj = new DBConn(); } # ~this() { delete obj; } #} #void main() { new Test(); } I would think this would be the 'preferred' pattern since (IMHO) an object like DBConn should always clean-up after itself anyhow. Calling delete on the object is allowed, the object just can't be dereferenced in the parent dtor. - Dave
Jul 31 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

Would something like this cause a complete re-write for you?

#class DBConn
#{
#    this() { ... }
#    ~this() { close(); }
#    void open() { ...  }
#    void close() { ... }
#}

#class Test
#{
#    DBConn obj;
#    this () { obj = new DBConn(); }
#    ~this() { delete obj; }
#}

#void main() { new Test(); }

I would think this would be the 'preferred' pattern since (IMHO) an object like
DBConn should always clean-up after itself anyhow.

The problem is that the object I'm using is not my own. I'm using Jeremy Cowgar's DDBI, which has explicit connect() and close() functions, and no destructor. What I had before worked because I inherited from the object, and I could call close() as my own function in my own destructor. But this forced me to inherit from a specific DB, like MySQL. To enable support for any DB type (PG, SQLite, etc.), I need to contain the database as a sub-object, and then create it depending on a parameter. When I made this change, the segmentation faults started because of the problem in the destructor. I could hack DDBI to auto-close the connection, but I'd rather not, since that's not its interface. In my opinion destructors are broken, and very limited. We should be able to reference sub-objects that don't do automatic cleanup precisely for cases like this. Thanks for the help. --AJG.
Jul 31 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
AJG <AJG_member pathlink.com> wrote:

[...]
 In my opinion destructors are broken, and very limited. We
 should be able to reference sub-objects that don't do automatic
 cleanup precisely for cases like this. 

Why is it not possible to embed the foreign object into a class with a subclass, whose destrcutor calls the cleanup procedure of the foreign object? Then because the subclass' destructor is executed before the embedding class' destructor the cleanup procedure will be executed before the foreign object is destroyed. -manfred
Jul 31 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi, 

Why is it not possible to embed the foreign object into a class with 
a subclass, whose destrcutor calls the cleanup procedure of the 
foreign object?

Because it's not just one type of object. It's a whole collection of possible sub-classes of a BaseDatabase class. # class MySQLDatabase : BaseDatabase { ... } # class PGSQLDatabase : BaseDatabase { ... } # class SQLiteDatabase : BaseDatabase { ... } # // and so on...
Then because the subclass' destructor is executed before the 
embedding class' destructor the cleanup procedure will be executed 
before the foreign object is destroyed.

Yeah, it's a possible workaround. At any rate, if you are doing this, it's essentially a hack to bypass the normal destructor restrictions, which shouldn't be there in the first place. Cheers, --AJG.
Jul 31 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
AJG <AJG_member pathlink.com> wrote:

Why is it not possible to embed the foreign object into a class
with a subclass, whose destrcutor calls the cleanup procedure of
the foreign object?

Because it's not just one type of object. It's a whole collection of possible sub-classes of a BaseDatabase class. # class MySQLDatabase : BaseDatabase { ... } # class PGSQLDatabase : BaseDatabase { ... } # class SQLiteDatabase : BaseDatabase { ... } # // and so on...

I do not understand this argument. If the subclasses represent different database types, then why is the cleanup procedure the same in all cases?
Then because the subclass' destructor is executed before the 
embedding class' destructor the cleanup procedure will be
executed before the foreign object is destroyed.

Yeah, it's a possible workaround.

No it is not a workaround as I found out: | The garbage collector is not guaranteed to run the destructor | for all unreferenced objects. And this restrictions follows in a natural way from the GC.
 bypass the normal destructor
 restrictions, which shouldn't be there in the first place.

Because of the GC they must be there and if you want to guarantee the execution of the cleanup operation you have to resort to deleting explictely. -manfred
Jul 31 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
 Because of the GC they must be there and if you want to guarantee the
 execution of the cleanup operation you have to resort to deleting
 explictely.

Or use the "auto" keyword. Regan
Jul 31 2005
prev sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,

Why is it not possible to embed the foreign object into a class
with a subclass, whose destrcutor calls the cleanup procedure of
the foreign object?

Because it's not just one type of object. It's a whole collection of possible sub-classes of a BaseDatabase class. # class MySQLDatabase : BaseDatabase { ... } # class PGSQLDatabase : BaseDatabase { ... } # class SQLiteDatabase : BaseDatabase { ... } # // and so on...

I do not understand this argument. If the subclasses represent different database types, then why is the cleanup procedure the same in all cases?

They all override a virtual void close(); finalization method to terminate the connection. In order for your solution to work, I'd have to wrap up (inherit from) every subclass in another object that calls this method as a protected member, whereas if I could reference the object in the destructor, I could just call .close() once in one single object. I don't know if that makes sense. If it doesn't could you provide an example of what you mean?
Then because the subclass' destructor is executed before the 
embedding class' destructor the cleanup procedure will be
executed before the foreign object is destroyed.

Yeah, it's a possible workaround.

No it is not a workaround as I found out: | The garbage collector is not guaranteed to run the destructor | for all unreferenced objects.

Oh, great. Yet another restriction.
And this restrictions follows in a natural way from the GC.

 bypass the normal destructor
 restrictions, which shouldn't be there in the first place.

Because of the GC they must be there and if you want to guarantee the execution of the cleanup operation you have to resort to deleting explictely.

Couldn't the GC just tag the objects that are needed and keep those from being collected until their containers' run their respective destructors? Cheers, --AJG.
Aug 01 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
AJG <AJG_member pathlink.com> wrote:

 I don't know if that makes sense. If it doesn't could you
 provide an example of what you mean? 

We need not try to explore this any further because it will not yield a solution.
 Couldn't the GC just tag the objects that are needed and keep
 those from being collected until their containers' run their
 respective destructors? 

D is built around the type of GC currently used. Especially tagging does not help in case of cyclic references. -manfred
Aug 01 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 I could hack DDBI to auto-close the connection, but I'd rather not, since 
 that's
 not its interface. In my opinion destructors are broken, and very limited. 
 We
 should be able to reference sub-objects that don't do automatic cleanup
 precisely for cases like this.

I agree destructors in D are very limited. They seem to be only useful for a class that owns an external resource that must be destroyed when the object is destroyed. To me that's ok if it gives the GC enough freedom to be faster and more predictable. I can see how one could say dtors in D are broken if one expects to use them like C++ or even Java/C#. If the Database subclasses that own an external resource do not have dtors then I'd request one from the author as a safety net. A user class holding a reference to a Database should not have a dtor since those classes do not own the external resource. In any case if the database dtor ends up closing the external resource it could very well be a bug since the user code should have closed the database long before the dtor ended up running.
Aug 01 2005
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
The issue here is that when 2 objects become garbage at the same time, 
there is no defined order in which they are cleaned up.  So, sometimes, 
the code like you wrote below will work, because the holder of the 
reference is destroyed first; other times, it won't, because they are 
cleaned up in the opposite order.

The reason that this problem exists is because the GC must deal with 
loops; when a loop of object references goes out of scope, what gets 
deleted first?



*** 'auto' solution ***
One solution is to use 'auto' objects. 
http://digitalmars.com/d/class.html says that auto objects don't have 
this ordering issue.  However, I don't think that you can reassign 
'auto' objects, so this is not an option if you will sometimes have to 
change the reference variable.



*** manual refcounting solution ***
Another solution is to find a way to make sure that the refered-to 
object is not garbage until after the referer dies; one way to do that 
is with an outside reference.  The code example below has an associative 
array which stores references to objects in a global; these references 
can be added to or removed as needed, to ensure ordering:

uint[Object] referenceTable;
void AddRef(Object o) {
   // you can write more efficient code (avoid the double lookup in
   // the AA) but this is easy to read for learning purposes.  Also,
   // this code is not thread-safe.

   if(o in referenceTable)
     referenceTable[o]++;
   else
     referenceTable[o] = 1;
}
void DelRef(Object o) {
   // again, double-lookup and thread safety issues.

   assert(o in referenceTable);
   referenceTable[o]--;
   if(referenceTable[o] == 0)
     referenceTable.remove(o);
       // don't delete, since somebody else in the world
       // might still have a reference.  Just drop this
       // reference, making it possible that this *might*
       // be garbage on the next pass.
}

class Test {
   Object obj = null;
   this () { obj = new Object(); AddRef(obj); }
   ~this() { obj.toString();     DelRef(obj); }
}

Uwe Salomon wrote:
 I took me a while to find and reduce this to a minimal example. I was  
 going nuts
 thinking it was my database abstraction layer. I think it's a bug in D.

 # // test.d
 # class Test {
 #     Object obj = null;
 #     this () { obj = new Object(); }
 #     ~this() { obj.toString();     }
 # }
 #
 # void main() { new Test(); }

 Segmentation Fault w/ DMD 0.128 on linux.

http://www.digitalmars.com/d/class.html#destructors "When the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references are no longer valid. This means that destructors cannot reference sub objects." So this is documented and correct behaviour. Ciao uwe

Aug 01 2005
parent reply "Walter" <newshound digitalmars.com> writes:
Generally speaking, destructors called by the garbage collector are not
terribly useful, for the reasons you mentioned. Destructors called when they
go out of scope (i.e. auto objects) are very useful.
Aug 02 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi Walter,

Generally speaking, destructors called by the garbage collector are not
terribly useful, for the reasons you mentioned. Destructors called when they
go out of scope (i.e. auto objects) are very useful.

What about getting the compiler to complain if there are sub-object member references in the destructor of a non-auto object, since they are not allowed? Would that be possible? It'd be an improvement. Thanks, --AJG.
Aug 02 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Generally speaking, destructors called by the garbage collector are not
 terribly useful, for the reasons you mentioned. Destructors called when  
 they
 go out of scope (i.e. auto objects) are very useful.

What about getting the compiler to complain if there are sub-object member references in the destructor of a non-auto object, since they are not allowed? Would that be possible? It'd be an improvement.

Hmm, but sub-object references are allowed for auto objects and objects that are explicitly deleted... This somehow seems like a design weakness to me. :( Ciao uwe
Aug 02 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

 Generally speaking, destructors called by the garbage collector are not
 terribly useful, for the reasons you mentioned. Destructors called when  
 they
 go out of scope (i.e. auto objects) are very useful.

What about getting the compiler to complain if there are sub-object member references in the destructor of a non-auto object, since they are not allowed? Would that be possible? It'd be an improvement.

Hmm, but sub-object references are allowed for auto objects and objects that are explicitly deleted... This somehow seems like a design weakness to me. :(

Yeah, but those would be fine. Auto-objects would be allowed. Delete Object would be allowed. Everything else (which is illegal, if I'm not mistaken), is disallowed. Right? Cheers, --AJG.
Aug 02 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Hmm, but sub-object references are allowed for auto objects and objects
 that are explicitly deleted... This somehow seems like a design weakness
 to me. :(

Yeah, but those would be fine. Auto-objects would be allowed. Delete Object would be allowed. Everything else (which is illegal, if I'm not mistaken), is disallowed. Right?

Yep. But how should the compiler know that? #### class SomeClass { SomeOtherClass m_cl; // ... ~this() { m_cl.doSomething(); } } SomeClass[] array; int main() { array ~= new SomeClass; array ~= new SomeClass; delete array[0]; } #### In this case the compiler would have to conclude that the second object in the array will be found by the GC. How to do that during compilation time? Ciao uwe
Aug 02 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

 Hmm, but sub-object references are allowed for auto objects and objects
 that are explicitly deleted... This somehow seems like a design weakness
 to me. :(

Yeah, but those would be fine. Auto-objects would be allowed. Delete Object would be allowed. Everything else (which is illegal, if I'm not mistaken), is disallowed. Right?

Yep. But how should the compiler know that? #### class SomeClass { SomeOtherClass m_cl; // ... ~this() { m_cl.doSomething(); } } SomeClass[] array; int main() { array ~= new SomeClass; array ~= new SomeClass; delete array[0]; } ####

In this case the compiler would have to conclude that the second object in  
the array will be found by the GC. How to do that during compilation time?

Ohhhhh... I see what you mean now. So if you call explicit delete on the _super_ object, then its destructor can safely access sub-object references, is that correct? That's just confusing and error-prone in my opinion. So depending on how it's deleted (GC vs. explicit) an object might (a) work perfectly, or (b) crash hard with a segmentation fault. I don't think that kind of design (and the behaviour that it causes) should be encouraged. I'm not sure what the compiler can do but I think it's a problem that should be thought about. I think (for now) maybe the compiler should emit at least a warning when referencing sub-objects in the destructor, given the hidden danger of doing so. Although fundamentally, the real solution would be to fix the GC so that it can deal with full-featured destructors. Cheers, --AJG.
Aug 02 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 Ohhhhh... I see what you mean now. So if you call explicit delete on the  
 _super_
 object, then its destructor can safely access sub-object references, is  
 that correct?

Exactly. Perhaps this would be a solution to your problem?
Aug 02 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:dcn7ss$1drb$1 digitaldaemon.com...
 Generally speaking, destructors called by the garbage collector are not
 terribly useful, for the reasons you mentioned. Destructors called when 
 they
 go out of scope (i.e. auto objects) are very useful.

This got me thinking about the uses of auto classes I've seen in D so far (note by auto objects I assume you mean an instance of an auto class). I've run into 4 auto classes: MmFile, ExeModule, PerformanceCounterScope (in phobos) and ScopedLock (in the locks library). The first two shouldn't be auto IMHO and MmFile is no longer auto. The last two are auto in order to ensure an action is performed at scope exit - either stop a performance counter or release a lock. Both of these auto classes can be replaced with the following auto class. By using this ScopeExit one can separate the concept of dtor called by the GC from the dtor called by exiting a scope. Also by reusing ScopeExit one can avoid ever having to define an auto class by hand. // the only auto class you'll ever need auto class ScopeExit { void delegate() dg; this(void delegate() dg) { this.dg = dg; } ~this(){ dg(); } } // example class Foo { void close() { printf("closing a Foo\n"); } } int main() { Foo f = new Foo; { auto ScopeExit exit = new ScopeExit(&f.close); printf("before exiting scope\n"); } printf("after exiting scope\n"); return 0; } Replacement code for the two auto classes PerformanceCounterScope and ScopedLock the code would look something like PerformanceCounterScope scope = new PerformanceCounterScope(counter); // original ScopeExit exit = new ScopeExit(&counter.stop); counter.start(); // new code ScopedLock scope = new ScopedLock(lock); // original code ScopeExit exit = new ScopeExit(&lock.unlock); lock.lock(); // new code
Aug 02 2005
parent Holger <Holger_member pathlink.com> writes:
In article <dcojar$2ggu$1 digitaldaemon.com>, Ben Hinkle says...
"Walter" <newshound digitalmars.com> wrote in message 
news:dcn7ss$1drb$1 digitaldaemon.com...
 Generally speaking, destructors called by the garbage collector are not
 terribly useful, for the reasons you mentioned. Destructors called when 
 they
 go out of scope (i.e. auto objects) are very useful.

This got me thinking about the uses of auto classes I've seen in D so far (note by auto objects I assume you mean an instance of an auto class). I've run into 4 auto classes: MmFile, ExeModule, PerformanceCounterScope (in phobos) and ScopedLock (in the locks library). The first two shouldn't be auto IMHO and MmFile is no longer auto. The last two are auto in order to ensure an action is performed at scope exit - either stop a performance counter or release a lock. Both of these auto classes can be replaced with the following auto class. By using this ScopeExit one can separate the concept of dtor called by the GC from the dtor called by exiting a scope. Also by reusing ScopeExit one can avoid ever having to define an auto class by hand. // the only auto class you'll ever need auto class ScopeExit { void delegate() dg; this(void delegate() dg) { this.dg = dg; } ~this(){ dg(); } } // example class Foo { void close() { printf("closing a Foo\n"); } } int main() { Foo f = new Foo; { auto ScopeExit exit = new ScopeExit(&f.close); printf("before exiting scope\n"); } printf("after exiting scope\n"); return 0; } Replacement code for the two auto classes PerformanceCounterScope and ScopedLock the code would look something like PerformanceCounterScope scope = new PerformanceCounterScope(counter); // original ScopeExit exit = new ScopeExit(&counter.stop); counter.start(); // new code ScopedLock scope = new ScopedLock(lock); // original code ScopeExit exit = new ScopeExit(&lock.unlock); lock.lock(); // new code

Neat! I like the idea. Cheers, Holger
Aug 02 2005