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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk