delete TFileStream and FileClose(TFileStream->Handle)

[finnmike]

Hello altogether!

I have a remark to make and a question in the end:

I use TFileStreams to append single AnsiStrings (TMemo->Text) at the end of a file. I am not using RichEdits (my files are in the end about 87k big) as it takes much too much time to append these strings to the Richedit and save it (I need to save it everytime , because I need the rest of the file when I get an exception).

I also used

  delete mystream;

when I was ready with the file.

Now I wanted to open the praticular file which was opened by the filestream once again after an exception, and I recieved a "cannot open/create" this file. What I did was not deleting the savestream properly in any case. After that was done the error still came up.

So in the next step I did it like this:

TFileStream  *MyStream = new TFileStream(AnyFileName, fmCreate);
delete MyStream;
TFileStream  *MyStream = new TFileStream(AnyFileName, fmOpenReadWrite);
...
delete MyStream;
FileClose(MyStream->Handle);

THIS IS SUGGESTED LIKE THAT IN THE BCB5 HELP!!!!!!!!!!!!!!!!!!
"use FileClose after You deleted the Stream Object"

And I got intermediate but worse errors as suddenly files were not exisiting which I didn't touch at all !!!!!!!!
(I even got a lot of WinAPI failures a.s.o.)

I risked not to do what is suggested. I interpreted the sentence "The handle of the Stream is freed before the object is deleted" as true and thought than it is natural that the MyStream_>YHAndle maybe points to another (unknown) file...

So I turned around the two lines (at any point in the code where I had it) to the following:

...
FileClose(MyStream->Handle);
delete MyStream;

and now I am so happy with it that I wanted to tell You that.

Has anybody similar experiences?

Do You think this is helpful or am I doing a very stupid and dangerous thing here?

Regards

Michael

 

[Totte]

As i see it You closes the file and THEN releases the stream i.e. the resources taken by the stream. This is according to what i've learned the way to do it. If You does not close the file but just releases the resources You has a file "dangling" somewhere in the system and off course it's unobtainable again.

Weather or not the destructor should close the file is not clear to me but my logic says that the stream could me much more than a file on harddisk and as such YOU has to close the file.

Totte

 

[Supernat03]

I agree. This was a misprint in Borland's help no doubt. You would never free memory, then try to access something from that memory. Just keep one simple process in mind and ignore the help if it claims to do otherwise

1) Never delete memory of an object before you are completely finished with it or unless you plan on instantiating a new object being pointed to by your pointer.

Also, always close a file being used as soon as possible after opening it. If you don't need it, close it, then operate on it's contents. It will save you a nightmare later.

I just read the help section in Borland 4, and it's the same problem. I'll have to check it out in version 6 and see if they also recommend doing that. That's pretty crazy I can only assume that they believe that their destructor closes the handle (though I don't know why they would still want you to close it), but from what you said, it probably doesn't...maybe something that just didn't get implemented and was forgotten about. Or perhaps they intended on you doing it this way:

int FileHandle = myStream->Handle;
delete myStream;
FileClose(FileHandle);

This should work and still satisfy what they are saying, but I haven't tried it.

Good luck,
Chris