• Max Samukha (10/10) Jan 26 2007 Are streams supposed to get closed when they are deleted? Currently
• Frits van Bommel (10/22) Jan 26 2007 It's probably more "by limitation".
• Max Samukha (7/29) Jan 26 2007 Thanks, Frits. I've overlooked the paragraph in the specs:
• Jarrett Billingsley (3/8) Jan 26 2007 Personally I think it should be changed outright..
• Frits van Bommel (4/14) Jan 26 2007 Feel free to modify the GC, thoroughly test it, and submit the patch to

Max Samukha <samukha voliacable.com> writes:

Are streams supposed to get closed when they are deleted? Currently
only file stream seems to work that way (its destructor calls
close()).

scope auto file = new File("file.txt");
// ok. file is closed at the end of the scope

scope auto file = new EndianStream(new BufferedFile("file.txt"));
// I expected the EndianStream's destructor would close the stream and
the underlying stream (nestClose is true) but that didn't happen.

It is by design?
 

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Max Samukha wrote:
 Are streams supposed to get closed when they are deleted? Currently
 only file stream seems to work that way (its destructor calls
 close()).
 
 scope auto file = new File("file.txt");
 // ok. file is closed at the end of the scope
 
 scope auto file = new EndianStream(new BufferedFile("file.txt"));
 // I expected the EndianStream's destructor would close the stream and
 the underlying stream (nestClose is true) but that didn't happen.
 
 It is by design?

It's probably more "by limitation".
File uses OS handles, so it can close those without any problems. If 
another Stream needs to be closed though, you can't really do that in 
the destructor. This is because if the garbage collector is the one 
calling the destructor, it may have already collected the underlying 
Stream and calling any methods on it produces Undefined Behavior. Which 
is a Bad Thing.
And since there's no way to tell if the object was deleted manually or 
by the GC, it's best not to touch any other objects in the destructor.

Max Samukha <samukha voliacable.com> writes:

On Fri, 26 Jan 2007 12:54:30 +0100, Frits van Bommel
<fvbommel REMwOVExCAPSs.nl> wrote:

Max Samukha wrote:
 Are streams supposed to get closed when they are deleted? Currently
 only file stream seems to work that way (its destructor calls
 close()).
 
 scope auto file = new File("file.txt");
 // ok. file is closed at the end of the scope
 
 scope auto file = new EndianStream(new BufferedFile("file.txt"));
 // I expected the EndianStream's destructor would close the stream and
 the underlying stream (nestClose is true) but that didn't happen.
 
 It is by design?

It's probably more "by limitation".
File uses OS handles, so it can close those without any problems. If 
another Stream needs to be closed though, you can't really do that in 
the destructor. This is because if the garbage collector is the one 
calling the destructor, it may have already collected the underlying 
Stream and calling any methods on it produces Undefined Behavior. Which 
is a Bad Thing.
And since there's no way to tell if the object was deleted manually or 
by the GC, it's best not to touch any other objects in the destructor.

Thanks, Frits. I've overlooked the paragraph in the specs:
"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."
Shouldn't it be in red bold underlined font? :)

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Max Samukha" <samukha voliacable.com> wrote in message 
news:bbvjr29j6nkd58e89t7m0oid09001sph72 4ax.com...

 Thanks, Frits. I've overlooked the paragraph in the specs:
 "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."
 Shouldn't it be in red bold underlined font? :)

Personally I think it should be changed outright.. 

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Jarrett Billingsley wrote:
 "Max Samukha" <samukha voliacable.com> wrote in message 
 news:bbvjr29j6nkd58e89t7m0oid09001sph72 4ax.com...
 
 Thanks, Frits. I've overlooked the paragraph in the specs:
 "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."
 Shouldn't it be in red bold underlined font? :)

 
 Personally I think it should be changed outright.. 

Feel free to modify the GC, thoroughly test it, and submit the patch to 
bugzilla...

(Oh, and make sure the performance doesn't suffer too much :p)