[Gdal-dev] Wide-character filenames with GDAL file IO?

Mateusz Loskot mateusz at loskot.net
Thu Sep 21 04:12:31 EDT 2006


Ben Discoe wrote:
>> second constructor you see, that takes const wchar_t* 
>> parameter is a non-standard *extension* introduced by Microsoft.
> 
> Well sure.  So is _wfopen, and _wfopen is great.
> The trouble here is not that it's a non-standard *extension*, but that it's
> a non-standard *extension* which appears in the docs but not in the product.
> :|

Ben,

My understanding is as follows, the extension has been introduced
with Visual C++ 8.0, so Visual C++ 7.1 does not include it.

>> That's why you can't find it in the MSVC++ 7.1
> 
> Well no, MSVC++ 7.1 has all of Microsoft's nonstandard extension, except
> (apparently) this one.

I can't agree.
Visual C++ 7.1. does not include *all* extensions, because many or most
of them have been introduced with Visual C++ 8.0, for example
safe version of C/C++ SL.

I mean, we can not expect both Visual C++ 7.1 and 8.0 include the
same version of standard and non-standard C/C++ features.
Also, new version of Visual C++ will likely include new stuff that won't
be backported to Visual C++ 2005.

>> Because, what I'm expalining above, there is no wide-char 
>> based ctor in basic_ifstream class, according to the C++ standard.
> 
> Yes, it's well known that the C and C++ standards are critically flawed in
> that they only support a local charset, not unicode.

Yes. Unicode handling is a matter of library but not the language,
in case of C/C++.

> This discussion isn't
> about standards, but about how we can implement support
> for all filenames in GDAL.

Yes, you're right.
I'm referencing to standards because I see standards as
the way to provide portable software.
So, if the wide-char ctor is only included in basic_ifstream of Visual
C++ 8.0, we can not use it because it's not portable.
That's why I usually try to stick to C/C++ standards and portable solutions.

I believe, portability is relevant to GDAL development.

> Fortunately for GDAL, it (apparently) sticks to C stdlib, so we can
> (thankfully) use _wfopen on Windows.

That's right.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net



More information about the Gdal-dev mailing list