Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2010-08-19 16:13:57

Boris Schaeling wrote:
> On Thu, 19 Aug 2010 01:18:56 +0200, Daniel Trebbien 
> <dtrebbien_at_[hidden]> 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.