$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Edward Diener (eddielee_at_[hidden])
Date: 2003-09-14 20:46:02
Adrian Michel wrote:
>> I reiterate, having a function that takes 'wchar_t' arguments
>> doesn't tell you much about the kind of unicode support. Yes, it
>> *may* be utf-16, but 'supports unicode' means a *lot* more than
>> that. Neither can you
>> deduce from
>> 'wchar_t' the kind of encoding actually used, nor is an interface
>> that understands
>> utf-16 automatically 'unicode aware'.
>>
>
> I am aware that in general the presence of wchar_t does not guarantee
> Unicode support. But on Windows at least, the absence of wchar_t
> guarantees the absence of Unicode support.
>
> Also, on Windows, as far as I can tell, Unicode is practically
> equivalent to using wchar_t, so to me seeing a method that takes a
> wchar_t* as parameter
> is at least an indication of Unicode support in that method.
>
> In any case, it seems to me that instances of boost::filesystem::path
> as it is implemented now, could not be created using Unicode strings
> on Windows.
C++ currently has no support for wide character filenames, so it isn't
surprising that Boost.Filesystem has no support for wide character
filenames.
I have argued on comp.std.c++ for C++ support for wide character filenames
in its fstream implementation in the future. Although I met much resistance,
I have been told that the case is not yet shut on this and that there is
interest in it connected to locales.