Using code similar to the following, I've noticed a problem in ifstream when using MBCS:
CFileDialog dlg(TRUE);
dlg.DoModal();
CString sFile = dlg.GetFileName();
ifstream stream(sFile, ios::in|ios::binary);
if (stream.good())
_tprintf(_T("Good\n"));
else
_tprintf(_T("Not good\n"));
Create a file somewhere called "abcžýášdef.TXT". Using Visual C++ 6.0, run the above code and select the file. You will notice that the output will be "Good". However, doing the same thing with Visual Studio 2008, the output will be "Not good".
Other file system functions just as _unlink(), CopyFile(), etc. all seem to handle the extended characters in the filename correctly. For some reason, ifstream does not.
I'll also add that if you pass this filename into ofstream, a file with the name "abcýádef.TXT" will be created. It looks like STL doesn't like the ž and š characters.
The solution, for now, is to convert the filename to wide characters (Unicode). This seems to work around whatever problem STL has.
Update July 25, 2008 17:07
Microsoft has acknowledged the bug. Now I have to wait and see if they'll fix it.
I saw some comments on the MSDN forums about this issue whereby they say it's not a bug, it's just the way it is. They said the solution is to convert your application to Unicode.
It most certainly is a bug. I cannot fathom how any developer would find it acceptable to ask the system to open a file, and for the system to respond success, but open another file.
Also, fopen() works correctly with the same file name.
In reality, the aforementioned "solution" is just a workaround. The real solution is to have Microsoft correct the problem. Besides, I just completed migrating my application from VC6 to VC9. I have no intention of migrating my 1.5 million lines of code to Unicode at this time.
Update August 7, 2008 17:02
No more responses from Microsoft.
You can access the problem's feedback document on Microsoft Connect.
If you're like me, and you want this fixed, please go there and vote to have this issue resolved.