Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1357
  • Last Modified:

CFile::GetLength and CFile::Read

Maybe a trivial question but I need to know this for sure once and for always. (so no trivial answers please)

I always see examples of reading a file's data by calling CFile::Read (or its Win32 equivalent or whatever equivalent) until there's no more data to read (the number of bytes read is less than the requested number of bytes). What's the reason for doing this?

Isn't it safe to just call CFile::GetLength and then CFile::Read with the requested length of the file?
0
searching
Asked:
searching
  • 2
  • 2
  • 2
  • +1
1 Solution
 
Roshan DavisCommented:
The file read have the maximum buffer length, so if you are calling the Read/ReadFile with greater than that size, it will just return the data with length of maximum buffer length.

Roshmon
0
 
Roshan DavisCommented:
Normally Buffer size is 4K,

So this is just for a safty.
If u have only less than that, u don't want to call ReadFile in a loop.

But for a generic program, that type of programming is peferable....

Roshmon
0
 
AlexNekCommented:
2 roshmon
about which 4K buffer are you talking? CFile::Read don't  use internal buffer, AFAIK.

2 searching
>Isn't it safe to just call CFile::GetLength and then CFile::Read with the requested length of the file?
It can't be always safe. In some cases you can read nothing or only a part of requested data. So it is good style to check number of bytes read.
"Buffer problem" can be with a big files.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
searchingAuthor Commented:
2 AlexNek

>It can't be always safe. In some cases you can read >nothing or only a part of requested data. So it
>is good style to check number of bytes read.

I can also check the number of bytes read using "CFile::Read(buffer, fileLength)" i.e. reading all of the file's data in one read operation.

>"Buffer problem" can be with a big files.
Do you mean a sort of buffer underrun problem? Is it likely that this problem will occur with big files?
0
 
peterchen092700Commented:
Some reasons:

* The buffer you use is smaller than the largest file you want to use (roshomon is prob. referring to this, although the 4K comes from something else)
* If you want to scan a huge file sequentially, it would be very ineffective to allocate a huge buffer (which is much more likely to fail), read it all at once, then scan it "in memory".
* If the file isn't opened exclusive, it could become longer or shorter beetween the GetLength() and the Read()
* Many things other than a File can hide behind a HANDLE (and so, to a lesser extent, behind a CFile)
* some implementations do intentially return "success" less bytes than specified were read. This might even be the cause for the same interface on different versions, or underlying storages
* block-by-block algorithms are generally more adaptable for different needs - e.g. if you want to switch to asynchronous read operations for better performance

* "It's the way we always did" ;-)

0
 
peterchen092700Commented:
The 4K buffer roshomon refers to is the standard cluster size on x86 platforms. This means: hard drive space is "allocated" to files in 4K units (so these 4K will always be sequential on disk). Virtual memory will be allocated in 4K chunks, and the memory manager will swap memory in 4K units (which is the actual reason for makingthe virtual memory chunks the same as the disk cluster size).

0
 
AlexNekCommented:
2  searching
>I can also check the number of bytes read using...
Yes, you can do it in specifically sample but in general it is not a good. [Peterchen] give you some examples.

while not eof do
  read buffer
  use buffer
end

This strategy for sequential file reading is better, at least, you don't need to know the file size. You can work with file and not thinking how big it is.
But if you have fixed file size, 512 bytes by sample, it can't be be a good sence use buffer with 64 bytes.


>"Buffer problem"
It is possible that with you strategy you can't allocate a big enough buffer. For really big files can be better use File Mapping.
0
 
searchingAuthor Commented:
Tnx to all. I accepted the answer of peterchen. (Can't accept all of your comments ;-))
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now