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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-08-19 15:14:57

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 read that the interprocess allocators of Boost.Interprocess  
> require a
> pre-existing shared memory segment. I was thinking about cross-platform
> versions of Windows' VirtualAllocEx
> function<http://msdn.microsoft.com/en-us/library/aa366890.aspx>which
> allows blocks of memory to be allocated directly within another
> process' address space, and
> ReadProcessMemory<http://msdn.microsoft.com/en-us/library/ms680553.aspx>/
> WriteProcessMemory
> <http://msdn.microsoft.com/en-us/library/ms681674.aspx>for accessing
> the memory.

Ah, I see! I'd say this belongs to Boost.Interprocess. ;-)

I'll probably not work on this anytime soon. In general I'm glad that  
after four years Boost.Process is so complete that I would dare to ask for  
a review. What Felipe and I had actually also planned was adding a  
create_snapshot() function and a parent class. So far Boost.Process is  
most useful when managing child processes. With create_snapshot() and  
parent it would also provide support to access non-related and parent  
processes. This would make the library a bit more complete (after all it's  
called Boost.Process and not Boost.ChildProcess :-).

If anyone wants to contribute some features though I'd definitely help to  
add them to the library!

> [...]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?

Boris