Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Lars Viklund (zao_at_[hidden])
Date: 2012-08-25 13:39:51

On Sat, Aug 25, 2012 at 08:51:53AM +0100, Alexander Lamaison wrote:
> Lars Viklund <zao_at_[hidden]> writes:
> 
> > 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?
> 
> 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_at_[hidden]