Subject: Re: [boost] [nowide] request for clarification
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2017-06-16 20:10:46
On Fri, Jun 16, 2017 at 6:12 PM, Andrzej Krzemienski via Boost
> Hi Everyone,
> I admit I am not quite familiar with the problem, but I understand that as
> one of the features, nowide offers a replacement for std::fstream that can
> be constructed with its string types. At the same time we have
> boost::filesystem that offers its own replacement for std::fstream that can
> be constructed with filesystem::path. Now, if I want to use
> `filesystem::path`s in my program (to be able to tell just any string from
> a filesystem path), can I still use the benefits of `nowide` library?
Yes of course. There is an integration between nowide and filesystem
to make sure it considers narrow API to be UTF-8.
Also note the nowide::fstream works on MinGW as well
as filesystem.fstream calls std::fstream and only MSVC version
has open(wchar_t const *).
> Also, in the docs for nowide::ifstream, we read, "Same as
> std::basic_ifstream<char> but accepts UTF-8 strings under Windows." What
> about other systems? What does it accept on Linux? ascii?
Under Linux it accepts "char *" in whatever encoding it is considered.
> In documentation for `nowide::args`, we read, "args is a class that fixes
> standard main() function arguments and changes them to UTF-8 under
> Microsoft Windows."
> Does it write to the input strings in-place? is it even legal in C++?
It replaces values of argc and argv and points them to other location
not modifying the original values.
> It "fixes", which implies that otherwise the args are "broken". How are
> args in function main() broken? (other than not being UTF-8)?
That main(argc,argv) receives parameters converted from native UTF-8
internal API to current locale's codepage - generally not being able
to represent the all the required charset (since Windows does not
support UTF-8 as native locale)