Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2012-08-25 18:31:59

Lars Viklund <zao_at_[hidden]> writes:

> 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.

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