Hi,
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 le
Hi,
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 r
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
On Sun, 26 Sep 2010 11:17:07 -0400, Tom Kazimiers <2voo...@gmx.de> 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
col
On Sun, 26 Sep 2010 20:20:18 -0400, Michel Fortin
wrote:
On 2010-09-26 10:06:33 -0400, "Simen kjaeraas"
said:
Tom Kazimiers <2voo...@gmx.de> wrote:
Hi,
a file reading class of mine can be constructed with a filename as
parameter. It instantiates a new std.stream.File (without the pass
On Sun, 26 Sep 2010 20:55:33 +0200, Tom Kazimiers wrote:
> If I would use std.stdio.File, what would be different?
Well, for one thing you won't have to write your code all over again when
std.stream is deprecated, which will happen soon. std.stdio.File is
really what you should use for file I/
On 2010-09-26 10:06:33 -0400, "Simen kjaeraas" said:
Tom Kazimiers <2voo...@gmx.de> wrote:
Hi,
a file reading class of mine can be constructed with a filename as
parameter. It instantiates a new std.stream.File (without the passed
file name and closes it when opened within the destructor. Th
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 obje
Tom Kazimiers <2voo...@gmx.de> wrote:
Hi,
On 09/26/2010 07:13 PM, bearophile wrote:
Tom Kazimiers:
Do you have any suggestion how I should make
sure that the file gets closed on destruction?
Can you use scope(exit) or the std.stdio.File?
Well, I have no idea. You mentioning scope(exit) w
Hi,
On 09/26/2010 07:13 PM, bearophile wrote:
> Tom Kazimiers:
>
>> Do you have any suggestion how I should make
>> sure that the file gets closed on destruction?
>
> 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 he
Tom Kazimiers:
> Do you have any suggestion how I should make
> sure that the file gets closed on destruction?
Can you use scope(exit) or the std.stdio.File?
Bye,
bearophile
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
Tom Kazimiers <2voo...@gmx.de> wrote:
Hi,
a file reading class of mine can be constructed with a filename as
parameter. It instantiates a new std.stream.File (without the passed
file name and closes it when opened within the destructor. The last part
is where things are getting unclear for me.
Hi,
a file reading class of mine can be constructed with a filename as
parameter. It instantiates a new std.stream.File (without the passed
file name and closes it when opened within the destructor. The last part
is where things are getting unclear for me. On the "file.isOpen()" call
in the destru
14 matches
Mail list logo
