Boris Schaeling wrote:
On Thu, 19 Aug 2010 01:18:56 +0200, Daniel Trebbien <dtrebbien@gmail.com> wrote:
[...]While there is no POSIX equivalent of the wide char functions, I was mainly thinking about using the `TCHAR` macro in cross-platform builds. Windows programmers will probably be programming with TCHAR set to `wchar_t`, so if the process creation library supported templating of the char type, then there wouldn't need to be conversion of wide char strings to narrow char strings. Plus, wouldn't there be a problem trying to execute a module on Windows that has a non-Latin character in it?
Ok, I'll look into it! I don't remember anymore all the details why I gave up quickly in previous versions. As the implementation has been simplified maybe it's easier now to support wide chars somehow.
I think we should wait for encoding-aware string class. It will allow to solve most of i18n issues in many libraries in a uniform way. The libraries I mean are Boost.Asio, Boost.Interprocess, Boost.System, Boost.Process and so on.
[snip]
[...]For some reason it looked strange to me that the find_executable_in_pathfunction returned a string rather than a Boost Filesystem path object. It's not that big of a deal, though, because I could construct a path from a string if I really wanted.
You are right, path makes sense here. I can change this if it is preferred?
-1. If you change find_executable_in_path() to return boost::filesystem?some?version?::path, then create_child(std::string, ) wouldn't accept the return value. If you change create_child() to accept boost::fs::path, then what type context::process_name, context::work_dir and others would have? The last but not least, Boost.Filesystem is not header-only.