Boost logo

Boost :

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
> 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<>which
> allows blocks of memory to be allocated directly within another
> process' address space, and
> ReadProcessMemory<>/
> WriteProcessMemory
> <>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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at