CFile vs FILE* vs FSTREAM
-
There are several ways to access files when coding in visual C. We could use CFile, or FILE* or fstream. Which one is the best in term of performance and stability ? What's your opinion ? I used to think that CFile would be the best choice when we work with Windows (because it was written by Microsoft anyway). But actually it's not. I have an application that do intensive disk read/write (it reads files from hard disk about 20 times per seconds) and I have checked it thoroughly to make sure there is no read/write conflict. If I use CFile, there is chance of about 5% it returns an error that it can't open file (mode: binary read) while the file is obviously available. If I replace that part with FILE* pointer (i.e. use fopen & fread) then It runs perfectly all the time.
-
There are several ways to access files when coding in visual C. We could use CFile, or FILE* or fstream. Which one is the best in term of performance and stability ? What's your opinion ? I used to think that CFile would be the best choice when we work with Windows (because it was written by Microsoft anyway). But actually it's not. I have an application that do intensive disk read/write (it reads files from hard disk about 20 times per seconds) and I have checked it thoroughly to make sure there is no read/write conflict. If I use CFile, there is chance of about 5% it returns an error that it can't open file (mode: binary read) while the file is obviously available. If I replace that part with FILE* pointer (i.e. use fopen & fread) then It runs perfectly all the time.
FILE* and fstream are good for cross platform stuff. FILE* is at a lower level than fstream and doesnt include the formatting and type conversion functionality. CFile is just a wrapper around the win32 native file io methods (CreateFile() etc) which is based on HANDLE's You have the soure code for the CFile class so you could debug it and find out why its failing
-
There are several ways to access files when coding in visual C. We could use CFile, or FILE* or fstream. Which one is the best in term of performance and stability ? What's your opinion ? I used to think that CFile would be the best choice when we work with Windows (because it was written by Microsoft anyway). But actually it's not. I have an application that do intensive disk read/write (it reads files from hard disk about 20 times per seconds) and I have checked it thoroughly to make sure there is no read/write conflict. If I use CFile, there is chance of about 5% it returns an error that it can't open file (mode: binary read) while the file is obviously available. If I replace that part with FILE* pointer (i.e. use fopen & fread) then It runs perfectly all the time.
Ultimately they are all wrappers around the same IO code. CFile is an MFC wrapper over the File APIs which are implemented using the internal copy of the C Library's FILE based system. 'fstream' is from the Standard Library implementation which is integrated with the User Mode C Library e.g. MSVCRT.dll so it ultimately uses FILE io blocks and the same low level code. With every layer of wrapping you get more convenience features and potentially more bugs. So you pays your money, in terms of ease of use, and you takes your choice. :)
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Ultimately they are all wrappers around the same IO code. CFile is an MFC wrapper over the File APIs which are implemented using the internal copy of the C Library's FILE based system. 'fstream' is from the Standard Library implementation which is integrated with the User Mode C Library e.g. MSVCRT.dll so it ultimately uses FILE io blocks and the same low level code. With every layer of wrapping you get more convenience features and potentially more bugs. So you pays your money, in terms of ease of use, and you takes your choice. :)
Nothing is exactly what it seems but everything with seems can be unpicked.
thanks, anyway, it's also a common sense to assume that things that were written earlier are buggy and later people not only improve functionality but also fix bugs to make them better :doh:
-
thanks, anyway, it's also a common sense to assume that things that were written earlier are buggy and later people not only improve functionality but also fix bugs to make them better :doh:
Hmm, with CRT code I think its almost the other way around. It's so old and has been hammered by so many millions of users and developers that its been refined by attrition to the point where it is both borderline unreadable gibberish and almost bulletproof as well. It's a kind of software aging where it has got both tougher and crustier with each round of modifications. MFC on the other hand has taken the work arounds approach where some of it has been broken for a decade, e.g. CSocket, with no proper fixes available because it's assumed everyone will use the documented work arounds or alternatives. Newer code isn't always better and wrappers don't always add reliability but we can hope :-D
Nothing is exactly what it seems but everything with seems can be unpicked.