kjteng
asked on
File and TFileStream
What is the advantage of using TFileStream over those conventional file IO routines, apart from the fact that
TFileStream is object oriented?
Sometimes I feel program using TFileStream is slower than those using blockRead, blockWrite, seek .... (just "feel" only, no statistics to prove).
Anyone can enlighten me?
TFileStream is object oriented?
Sometimes I feel program using TFileStream is slower than those using blockRead, blockWrite, seek .... (just "feel" only, no statistics to prove).
Anyone can enlighten me?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1) See classes.pas in Delphi 3\Source\VCL
See blockrea.asm, blockwri.asm in Delphi 3\Source\RTL\SYS
2) No. TFileStream and BlockRead and BlockWrite works same, they call
WinAPI function
See blockrea.asm, blockwri.asm in Delphi 3\Source\RTL\SYS
2) No. TFileStream and BlockRead and BlockWrite works same, they call
WinAPI function
ASKER
Thanks for telling me that the vcl source are included in delphi 3 - I didn't notice this because the source code (limited vcl only) was available only in c/s version CD for delphi 1.
I think tFileStream may not be so efficient if we need to change file during runtime because we need to destroy the existing fileStream object and create a new one. I may be wrong ... I have to check the source code to see how this is done.
I think tFileStream may not be so efficient if we need to change file during runtime because we need to destroy the existing fileStream object and create a new one. I may be wrong ... I have to check the source code to see how this is done.
What do you mean "tFileStream may not be so efficient if we need to change file during runtime"
Where is problem?
Why do you need to destroy the existing fileStream object and create a new one?
If you want modify file you can use two filestreams: first for reading, second for writing
For example:
InStream := TFileStream.Create('in.dat ', fmOpenRead);
try
OutStream := TFileStream.Create('out.da t', fmCreate);
try
while InStream.Position < InStream.Size do
begin
InStream.ReadBuffer(InBuff er, SizeOf(InBuffer));
{ modify InBuffer -> OutBuffer }
OutStream.WriteBuffer(OutB uffer, SizeOf(OutBuffer));
end;
finally
OutStream.Free;
end;
finally
InStream.Free;
end;
If you modify part or file and size of part not change you can use ONE file stream:
for reading and writing.
How can you do it more efficiently with BlockRead and BlockWrite???
Where is problem?
Why do you need to destroy the existing fileStream object and create a new one?
If you want modify file you can use two filestreams: first for reading, second for writing
For example:
InStream := TFileStream.Create('in.dat
try
OutStream := TFileStream.Create('out.da
try
while InStream.Position < InStream.Size do
begin
InStream.ReadBuffer(InBuff
{ modify InBuffer -> OutBuffer }
OutStream.WriteBuffer(OutB
end;
finally
OutStream.Free;
end;
finally
InStream.Free;
end;
If you modify part or file and size of part not change you can use ONE file stream:
for reading and writing.
How can you do it more efficiently with BlockRead and BlockWrite???
ASKER
You got me wrong.
I agreed that TFileStream provides a clean/elegant way of file handling. I do use TFileSTream instead of BlockRead/BlockWrite most of the time. What I want to know is whether is there any circumstances where I should not use TFileStream.
In my case, I am writing some components which manage file/data in a way similar to the ttable component but these components do not require the BDE. At any time the user are allowed to change the name of file related to the component (just like we can change tablename property of a ttable). If I use TFileStream, I need to recreate the fileStream object everytime when the user change the filename propery. If I use the conventionally way, i only need to assign the filename and reset/rewrite the file. I am not sure which is the better approach.
I agreed that TFileStream provides a clean/elegant way of file handling. I do use TFileSTream instead of BlockRead/BlockWrite most of the time. What I want to know is whether is there any circumstances where I should not use TFileStream.
In my case, I am writing some components which manage file/data in a way similar to the ttable component but these components do not require the BDE. At any time the user are allowed to change the name of file related to the component (just like we can change tablename property of a ttable). If I use TFileStream, I need to recreate the fileStream object everytime when the user change the filename propery. If I use the conventionally way, i only need to assign the filename and reset/rewrite the file. I am not sure which is the better approach.
Ok. Let's compare
If you don't use FileStream then your code look like
procedure Recreate;
begin
CloseFile(F); // or Close(F) - you must close old file
AssignFile(F, NewFileName); // or Assign(F, NewFileName)
Reset(F); // or Rewrite(F) - open file
end;
When you use FileStream
procedure Recreate;
begin
FStream.Free; // close old FileStream
FStream := nil;
FStream := TFileStream.Create(NewFile Name, fmOpenReadWrite); // open new FileStream
// or TFileStream.Create(NewFile Name, fmCreate)
end;
If you look at Delphi source you find that
CloseFile(F) - call WinAPI CloseHandle function
AssignFile - does not call WinAPI function
Reset(F) or Rewrite(F) - call WinAPI CreateFile function
FStream.Free - call WinAPI CloseHandle function
FStream := nil - does not call WinAPI function :-)
TFileStream.Create - call WinAPI CreateFile function
They are EQUIVALENT
May be you mean that when we use FileStream
we spend much time for creating/destroing object.
I think it is not the case.
I think we spend much more time for reading/writing data.
In this case we determined that using FileStream and BlockRead/BlockWrite
is equivalent.
If you don't use FileStream then your code look like
procedure Recreate;
begin
CloseFile(F); // or Close(F) - you must close old file
AssignFile(F, NewFileName); // or Assign(F, NewFileName)
Reset(F); // or Rewrite(F) - open file
end;
When you use FileStream
procedure Recreate;
begin
FStream.Free; // close old FileStream
FStream := nil;
FStream := TFileStream.Create(NewFile
// or TFileStream.Create(NewFile
end;
If you look at Delphi source you find that
CloseFile(F) - call WinAPI CloseHandle function
AssignFile - does not call WinAPI function
Reset(F) or Rewrite(F) - call WinAPI CreateFile function
FStream.Free - call WinAPI CloseHandle function
FStream := nil - does not call WinAPI function :-)
TFileStream.Create - call WinAPI CreateFile function
They are EQUIVALENT
May be you mean that when we use FileStream
we spend much time for creating/destroing object.
I think it is not the case.
I think we spend much more time for reading/writing data.
In this case we determined that using FileStream and BlockRead/BlockWrite
is equivalent.
ASKER
>May be you mean that when we use FileStream we spend much time for creating/destroing object ...
Yes, that was what I thought.
I have just tested both ways with a simple program (by repeatedly changing the filename property and then read 100 records, repeat this 1000 times) and the results shows that tFileStream is slower by <0.1 sec.
Considering the merits of oop, I think I should use TFileStream.
Thanks again vladika for spending time to answer my question.
Yes, that was what I thought.
I have just tested both ways with a simple program (by repeatedly changing the filename property and then read 100 records, repeat this 1000 times) and the results shows that tFileStream is slower by <0.1 sec.
Considering the merits of oop, I think I should use TFileStream.
Thanks again vladika for spending time to answer my question.
ASKER
1. where can I find the classes.pas file?
2. is tstream slower?
BTW, I will like to hear the comment from other experts, if everybody is of the same opionion as you, you shall get the points.