Subject: Re: [boost] [boost.process] Review
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-09-25 10:56:48
Am 16.09.2016 um 14:24 schrieb Klaim - JoÃ«l Lamotte:
> On 14 September 2016 at 18:08, Klemens Morgenstern <
> klemens.morgenstern_at_[hidden]> wrote:
>> Am 14.09.2016 um 16:29 schrieb Klaim - JoÃ«l Lamotte:
>>> I share these concerns.
>> It's not easy to solve, it would probably look like this:
>> child c("Ã¤Ã¶Ã¼", windows::unicode);
> Looks ugly but I'm not specialist in solving this problem
> Would it be a problem to just allow wstring too, and like
> boost::filesystem, assume it's UTF-16's for window's wide API on Windows?
>> I do however think, that such cases are rather rare for processes, while
>> they might be regular for filesystems.
> Unfortunately, as soon as you launch processes on windows, you must assume
> that the name of the process
> might have unicode characters, so in general it is better to use the wide
> API (UTF-16 like) anyway.
> As allow providing bfs::paths I guess that it's taken care of, but then the
> internals of boost::process which use the windows API must use
> the internal representation of bfs::path (through the native() function)
> which do store pathsin UTF-16.
I implemented a alpha for a wchar_t (which is UCS-2 on windows) version,
which works similar to boost.filesystem. You can change the locale by
calling boost::process::imbue. It's not yet tested or even implemented
on posix, but it seems to work thus far.
You can check it out here:
If any element that requires wchar_t is passed, everything gets
converted to wchar_t on windows, but on linux all wchar_t elements will
be converted to char.
On windows boost::filesystem::path requires wchar_t, so that case may
occur rather often.
Once I've implemented that on posix, I'll add more tests and documentation.