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:
https://github.com/klemens-morgenstern/boost-process/tree/codecvt
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.