Hi all,
I want to find the end of file in a CFile. What I've do up to now is, find the length of the file in bytes. Then do the required process with the number of bytes. Here is the code,
int length = 0 ;
CString str
length = srf_ReadFile.GetLength()/sizeof(TCHAR) ;
str.Format(_T("File size is %d bytes long."), length) ;
AfxMessageBox(str, MB_OK) ;My question is there is any simple way to do it. I know on fstream I can do it within one statement, like this.
while(!fileopen.eof())Jump to Posteven the fstream example you posted is not workable.
line 4 does not calculate the size of a file but the number of TCHARs in the file, which might or might not be the same as the size depending on the UNICODE setting.
As for CFile, the answer …
Jump to Post>>Actually it works
Yes it will work if you do not define UNICODE because TCHAR is defined as char and sizeof(char) is always 1. So your code reduces to srf_ReadFile.GetLength()/1, or just simply srf_ReadFile.GetLength(). Now define UNICODE and your formula will change to srf_ReadFile.GetLength()/2, which will result in 1/2 of …
even the fstream example you posted is not workable.
line 4 does not calculate the size of a file but the number of TCHARs in the file, which might or might not be the same as the size depending on the UNICODE setting.
As for CFile, the answer is NO -- and that's one reason why I hate that class. Unless the file contains serialized MFC objects you are better off using normal c++ fstreams, assuming your compiler supports it (some do not).
even the fstream example you posted is not workable.
At the time I post my code it's not workable. But now it works. What I want to do is try the same application with CFile and SQL Server. And also I want to design a GUI for it later.
line 4 does not calculate the size of a file but the number of TCHARs in the file, which might or might not be the same as the size depending on the UNICODE setting.
Actually it works, I check the properties of the file(file which is used to read) and the number of bytes of the file is same as the value given by the above code.
As for CFile, the answer is NO -- and that's one reason why I hate that class. Unless the file contains serialized MFC objects you are better off using normal c++ fstreams, assuming your compiler supports it (some do not).
Most of the time I found that, people don't like MFC. Few reasons I have to use it. First thing is I want to design GUI. Second thing is I'm really new for C++ and MFC, and I'm searching the easiest way to do it.
>>Actually it works
Yes it will work if you do not define UNICODE because TCHAR is defined as char and sizeof(char) is always 1. So your code reduces to srf_ReadFile.GetLength()/1, or just simply srf_ReadFile.GetLength(). Now define UNICODE and your formula will change to srf_ReadFile.GetLength()/2, which will result in 1/2 of the actual file size if you are on MS-Windows or 1/4th the file size on *nix because sizeof(TCHAR) = 2 (a short int) on MS-Windows and sizeof(TCHAR) is 4 on *nix (a long int)
>>Few reasons I have to use it. First thing is I want to design GUI
Not a reason to use CFile. Just because you have an MFC program is not a reason to use CFile either. You can mix CFile with fstreams in the same program -- I have done it hundreds of times.
Thanks pal,
Not a reason to use CFile. Just because you have an MFC program is not a reason to use CFile either. You can mix CFile with fstreams in the same program -- I have done it hundreds of times.
Actually I haven't use it before. If I can use fstream in an MFC application what is the point to use CFile. Any special reason to do it.
CFile is often used with CArchive to serialize MFC classes and objects. Otherwise its not a very good class for normal text file i/o.
Actually lots of people hate this MFC. But I feel it is easy to learn.
And as you say, if I can use functionalities like fstream, etc it wont be difficult at all.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.