On Sat, Aug 25, 2012 at 08:51:53AM +0100, Alexander Lamaison wrote:
Lars Viklund <zao@acc.umu.se> writes:
On Fri, Aug 24, 2012 at 10:27:25PM +0100, Alexander Lamaison wrote:
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?).
Files like Windows.h are not immutable things. There's many providers of it, like mingw-w64, all the Windows SDKs, the Visual Studio include directories before the introduction of the Platform SDK, and so on.
Do you really want the maintenance nightmare of ensuring that your declarations and definitions of everything remains correct for all future releases of the headers, both backwards and forwards?
The create process API is not going to change!
Implementation-wise, I'd say that a mingw-w64 and a WSDK Windows.h differ greatly in implementation, and if you start reinventing them, you'll end up with all sorts of awesome mismatches, particularly if the user then includes the Real Deal.
If your redeclaration of the CreateProcess differs from what's in those headers you program won't even link so you'll find out you screwed up pretty quickly.
I thought that the discussion had threaded into the generic approach of reinventing a platform header, not your particular use case. For many things, there are rather significant differences in the declarations, of which not all of them are hard errors. I'd rather have a slightly more polluted library that is sure to follow changes going forward, instead of praying that things you cannot foresee won't happen. Worst of all, if you have a slightly different declaration, you'll get massive rantage from the compilers, and at worst, subtle changes in semantics. -- Lars Viklund | zao@acc.umu.se