Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Lars Viklund (zao_at_[hidden])
Date: 2012-08-24 20:20:18

On Fri, Aug 24, 2012 at 10:27:25PM +0100, Alexander Lamaison wrote:
> Jeff Flinn <Jeffrey.Flinn_at_[hidden]> 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?

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.

-- 
Lars Viklund | zao_at_[hidden]