GIDForums  

Go Back   GIDForums > Computer Programming Forums > CPP / C++ Forum
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
 
Thread Tools Search this Thread Rate Thread
  #1  
Old 07-Sep-2005, 06:37
gaoanyu gaoanyu is offline
New Member
 
Join Date: Jun 2005
Location: Bristol, UK
Posts: 26
gaoanyu is on a distinguished road

fflush()?


Dear friends,

I am wirting a program that involves a great deal of writing to files. In order to constantly checking the file size , I have included a lot lines of fflush(), so that I can use ftell(File) in the debug window to monitor the size of the file on the fly. I am not sure if this is good practice, is there a down side of using fflush so many times? Thanks in advance for your replies!

Best regards,
Dave
  #2  
Old 07-Sep-2005, 10:23
L7Sqr L7Sqr is offline
Member
 
Join Date: Jul 2005
Location: constant limbo
Posts: 103
L7Sqr will become famous soon enough
fflush flushes the buffer and forces a write to file.
You can use unbuffered write calls to avoid needing to rely on a call to fflush. However, the reliability will come at the cost of what the buffering provides.
  #3  
Old 07-Sep-2005, 10:43
maprich maprich is offline
Member
 
Join Date: May 2005
Posts: 163
maprich has a spectacular aura aboutmaprich has a spectacular aura about
Speaking generally here: The less bytes you write between each fflush() the slower your program is. fflush() is best used only before closing the file to ensure that everything from the write buffer gets sefely to the file.

The file IO operations are relatively slow operations (e.g. compared to memory) involving seek time, write speed and read speed. Therefore it's better to use buffers to make IO more effective. A larger chunk of bytes gets written once. If every small piece of data was to be written separately it follows that for every piece the harddisk spends time in searching the correct place to continue the writing (==seek time). And that is exactly what happens if you force the system with repetitive use of fflush().

If you are appending to an existing file then you can use ftell() once right after opening the file so that your program knows the initial size of the file. Then you should keep a counter variable which you increase by the amount of written bytes every time you write to the file.

It would be also interesting to know what exactly your program needs to monitor the filesize for. Is it because of targetting for some limitation like floppysize 1.44 MB ? If so then keep in mind that you need to take into account some overhead for the actual size in the filesystem. One reason is the allocation unit size used by the filesystem.
Last edited by maprich : 07-Sep-2005 at 11:07. Reason: edited poor language
  #4  
Old 07-Sep-2005, 11:58
WaltP's Avatar
WaltP WaltP is offline
Outstanding Member
 
Join Date: Feb 2004
Location: Midwest US
Posts: 3,234
WaltP is a name known to allWaltP is a name known to allWaltP is a name known to allWaltP is a name known to allWaltP is a name known to allWaltP is a name known to all
Quote:
Originally Posted by maprich
Speaking generally here: The less bytes you write between each fflush() the slower your program is. fflush() is best used only before closing the file to ensure that everything from the write buffer gets sefely to the file.
Why would fflush() be best used before closing the file? Closing the file already flushes the file! fflush() is best used when you wish to make certain data gets into the file when you do not want to close the file.

Quote:
Originally Posted by maprich
The file IO operations are relatively slow operations (e.g. compared to memory) involving seek time, write speed and read speed. Therefore it's better to use buffers to make IO more effective. A larger chunk of bytes gets written once. If every small piece of data was to be written separately it follows that for every piece the harddisk spends time in searching the correct place to continue the writing (==seek time). And that is exactly what happens if you force the system with repetitive use of fflush().

Generally, this is very true. But if your data is critical, and losing some because of a problem would be a disaster, the output should be written as soon as it's available.

Quote:
Originally Posted by maprich
If you are appending to an existing file then you can use ftell() once right after opening the file so that your program knows the initial size of the file. Then you should keep a counter variable which you increase by the amount of written bytes every time you write to the file.
I agree with the concept of keeping track of the file size by incrementing counters. That way in the debugger all you need to do is watch the counters and not execute the ftell() function.
__________________

Cow: You're a lawyer too?
Mooseblood (mosquito): Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase!
  #5  
Old 14-Sep-2005, 11:29
gaoanyu gaoanyu is offline
New Member
 
Join Date: Jun 2005
Location: Bristol, UK
Posts: 26
gaoanyu is on a distinguished road
Dear friends,

Thanks a lot for all your responses.

The reason I want to examine the file size is I want to fit the generated stream into packets in order to transmit over the Internet.

It seems now that inserting a counter is a better way. I think I will go from here, thanks again guys!

David
 

Recent GIDBlogPrepping for deployment by crystalattice

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Things to Avoid in C/C++ -- gets() , Part 1 WaltP C Programming Language 5 21-Jun-2007 12:13
[Tutorial] Standard I/O aaroncohn C Programming Language 20 27-Feb-2004 21:07

Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The

All times are GMT -6. The time now is 02:05.


vBulletin, Copyright © 2000 - 2008, Jelsoft Enterprises Ltd.