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 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