View mode: basic / threaded / horizontal-split · Log in · Help
September 27, 2010
Re: Segmentation fault on closing file in destructor
On Sun, 26 Sep 2010 11:17:07 -0400, Tom Kazimiers <> wrote:

> Hi Simen,
> On 09/26/2010 04:06 PM, Simen kjaeraas wrote:
>> Likely, it is this[1]:
>> "[T]he order in which the garbage collector calls destructors for
>> unreference objects is not specified. This means that 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 may
>> no longer be valid. This means that destructors cannot reference sub
>> objects."
>> [1]:
> thanks for your reply. I did not know that the garbage collector works
> that way. Is the reason for that flexibility for the GC? What if I want
> to handle some destruction parts to sub-objects or if I want conditions
> while destruction, based on sub-objects?

Then do not use a destructor.  There is no way currently for the  
destructor to know whether it's being called from the GC or not, so it is  
only safe to destroy resources *not* allocated by the GC.  In fact, the  
only reason destructors are supported in classes is to destroy non-GC  

> Or maybe I should generally
> avoid situations like that. Do you have any suggestion how I should make
> sure that the file gets closed on destruction?

You don't have to worry about it -- let the GC do its job.  If you think  
about it, your class instance may have the only reference to the File  
object.  Since your class is being destroyed by the GC, it makes sense  
that the File object has no references to it, so it too is being destroyed  
by the GC.  If you want sooner destruction, you should manually close it  
earlier via another function call (like close() or detach()).

However, I will mention something that others missed, unlike in C++, the  
default protection in a class is public, so your public: attribute doesn't  
do much, and your file member is publicly accessible.

September 28, 2010
Re: Segmentation fault on closing file in destructor
Hi Jérôme,

On 09/26/2010 10:59 PM, "Jérôme M. Berger" wrote:
> 	The way I see it, there are two possible situations:
> 1. You really need precise control as to when the file is closed. In
> that case, your class contains an explicit cleanup function that you
> call before dropping the last reference and you can close the file
> at that time;
> 2. You only need to be sure that the file gets closed at some point
> but it doesn't really signify when. In that case, you let the GC
> collect your class and you don't close the file. Eventually the GC
> will collect the instance which will result in
> calling its destructor which will close the file without your
> needing to do anything about it.

That are probably the two choices I have, yes. I already have such a
cleanup function and will probably go for that.

September 28, 2010
Re: Segmentation fault on closing file in destructor

On 09/26/2010 10:05 PM, Simen kjaeraas wrote:
>>> Can you use scope(exit) or the std.stdio.File?
>> Well, I have no idea. You mentioning scope(exit) was actually the first
>> time I heard of it. Unfortunately I have not found any resource about
>> it. Do you have a link to point me in the right direction?

thanks, strange I did not find that page by searching. Good to know
about that concept, but I guess it is not fitting as a solution here. My
scope is the from creation to destrution of the class, so this will no
be working. But anyway, thanks.

September 28, 2010
Re: Segmentation fault on closing file in destructor

On 09/27/2010 02:09 PM, Steven Schveighoffer wrote:
> On Sun, 26 Sep 2010 20:20:18 -0400, Michel Fortin
>> In fact, it's generally a good idea to not wait for the GC to collect
>> your objects before closing files, because waiting for the GC could
>> take an indeterminate amount of time and leave files open for a long
>> time (the GC only runs when needed).
> Yes, this is true no matter what File construct you use.

I'll keep that in mind and will go for a cleanup method that I have to
call explicitely. Especially files should probably only be opened if in
use or if one wants to prevent others from using it.

Next ›   Last »
1 2
Top | Discussion index | About this forum | D home