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]>
> [...]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
> 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
> allows blocks of memory to be allocated directly within another
> process' address space, and
> <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
> path object. It's not that big of a deal, though, because I could
> a path from a string if I really wanted.
You are right, path makes sense here. I can change this if it is preferred?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk