Am 16.09.2016 um 14:24 schrieb Klaim - Joël Lamotte:
On 14 September 2016 at 18:08, Klemens Morgenstern < klemens.morgenstern@gmx.net> 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.