Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-23 10:31:03

I'm working on more file system functionality (to be packaged with
Dietmar's directory iterators).

At 07:48 AM 1/30/2002, Ken Hagan wrote:

>... at least in the Windows world, a mounted filesystem will either
>store names on the disc in "the current code page" (MS-DOS and early
>Windows) or as "Unicode" (FAT32 and NTFS). For this reason, semi-
>serious manipulation of files and file systems on NT/2K/XP is done
>with wchar_t rather than char. The latter is simply blind to a range
>of names that might exist. (There's another reason too, since the
>char-based APIs can't handle paths longer than 260 characters, and
>this limit can be exceeded by UNC-style names.)

How does this work? The Win32 API traffics mostly in character strings.

For example, say we have a function template:

   template< typename CharT >
   bool exists( const std::basic_string<CharT> & path );

The Win32 char implementation might look like this:

   template<> // specialization for char
   bool exists<char>( const std::basic_string<char> & path )
     return GetFileAttributes( path.c_str() ) != 0xFFFFFFFF;

What does the wchar_t implementation look like? There isn't a
GetFileAttributes overloaded for wchar_t; GetFileAttributes itself is
apparently Unicode enabled. I guess that means the wstring path argument
has to be converted somehow before calling GetFileAttributes().

I'd appreciate seeing the preferred code from someone who has actual
experience with Unicode path names.



Boost list run by bdawes at, gregod at, cpdaniel at, john at