Jeff Flinn <Jeffrey.Flinn@gmail.com> writes:
On 8/23/2012 4:58 AM, Matus Chochlik wrote:
I've struggled with just what a "child" entails as well. In our uses, a "child" instance may be a data member of a class. In trying to maintain process as a header only library, having the child hold a window's handle exposes windows.h too widely. I've thought the child could merely hold a pid (like posix), and the corresponding handle could be retrieved only when needed. I'm not sure yet if there are any issues with doing this in general on windows. This windows.h visibility is the motivation for the separate "monitor" type in my design. The monitor, typically being isolated to a few translation units as required, avoiding windows.h in any headers. There are both "monitor" and a "scoped_monitor" types.
Why is it necessary to Windows.h at all? Projects that don't want to have a dependency on it usually just redeclare the API function (in this case CreateProcess) and the necessary structs (PROCESS_INFORMATION?). Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)