Lars Viklund <zao@acc.umu.se> writes:
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.
It applies to an core OS API. The whole point of an OS API (more importantly, an OS ABI) is that it cannot change (modulo architecture) or binaries are unable to run.
For many things, there are rather significant differences in the declarations, of which not all of them are hard errors.
The declaration differences are purely syntactic. Eventually they all have to desugar into the exact same types (modulo architecture). Even assembly programmers have to be able to call these functions and know it will work.
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.
There aren't going to be any breaking changes unless we move to 128-bit architectures or Microsoft decide to drop backward compatibility and start Windows again from scratch.
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.
If you have a semantically different declaration it's not going to work anyway. The compiler should ignore syntax differences. Alex