Unportable string handling in API

[alamaison]

The way char vs wchar_t strings are handled on Windows makes hard to write portable code. Currently, if UNICODE is defined the API is wide and if not it is narrow. On POSIX it is always narrow.

The only way to write portable code with this API is to use the preprocessor to select completely separate implementations based on #ifdef UNICODE.

Instead both narrow and wide versions should always be defined and it is up to the caller which they use.

The problem did not exist in previous versions of Boost.Process.

[klemens-morgenstern]

You can pull this from my fork, where it's templated. Thus it allows char and wchar_t on windows.

Do you know if anyone actually uses the wchar_t variants? I am working on a new version, but I completely removed them, because I never touch them.

[alamaison]

You can pull this from my fork, where it's templated

Thanks.

Do you know if anyone actually uses the wchar_t variants?

You have to on Windows if you want Unicode because the narrow API doesn't support UTF-8. Unless you do something like Boost.Filesystem that allows you to pass a locale which can be set to interpret narrow strings as UTF-8. Or like Boost.Locale that always assumed narrow strings are UTF-8.