Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-11-14 05:00:49

On Nov 13, 2012, at 5:17 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Le 13/11/12 22:39, Boris Schaeling a écrit :
>> On Thu, 08 Nov 2012 01:08:21 +0100, Alexander Lamaison <awl03_at_[hidden]> wrote:
>> 
>>> [...]Does this mean child *is* copyable on other platforms?  So the class has
>>> entirely different semantics on different platforms?
>> 
>> Yes. It doesn't own resources on POSIX.
>> 
>> I understand what you hint at. I'm not sure though whether we can justify making child non-copyable for POSIX developers just because Windows developers can't copy it.
> Uniformity is better.

+1

Why must child be copyable?  Just because the underlying implementation permits it doesn't mean that you must permit it in your abstraction.

> The native_handle could be copyable and this could be platform specific. This make evident that the code is platform specific as the type is platform specific.

Agreed

>> 
>>> [...]I still don't get why you're letting this behaviour vary between
>>> platform.  Sure, the underlying system calls have different defaults but
>>> they are both capable of both behaviours.  The whole point of a
>>> platform-independent library is to align such variation.
>> 
>> If you use inherit_env(), you get the cross-platform behavior you are looking for. But I prefer not to break the "pay for what you use"-principle if you don't use inherit_env().

What cost is there, in each case, to deviate from the default? Is it possible that Windows inherit default is actually costlier than disabling it? (I don't know how it's implemented or if not inheriting just undoes work already done.)

>> Besides, standardizing the default behavior requires you to pick one. But whether this should be always POSIX, always Windows, always the most convenient or always the easiest to implement - I'm afraid there will be always others who want another default behavior.
>> 
> One alternative is to make it inherit by default, so that a common behavior is ensured.

As you noted before, uniformity is better.

> Then you can provide a platform specific constructor on the platform allowing to don't inherit the environment.

How about an argument that defaults to whichever you like, but offers three choices: inherit, don't inherit, and don't care. Document the cost of the first two on each platform, and describe the third as giving the platform default. (If there's actually a cost inherent to Windows' default, "don't inherit" could be preferable, and you wouldn't need the "don't care" option.)

___
Rob