Re: [boost] Boost.Process: Formal review request

Subject: Re: [boost] Boost.Process: Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2012-12-13 06:23:45

On 2012-12-12 23:47, Boris Schaeling wrote:
> On Sun, 09 Dec 2012 14:13:27 +0100, Klaim - Joël Lamotte
> <mjklaim_at_[hidden]> wrote:
>
>> On Sun, Dec 9, 2012 at 2:06 PM, Roland Bock <rbock_at_[hidden]> wrote:
>>
>>> I say: Do both.
>>>
>>> * Abstract away all differences for those who do not care about
>>> platform
>>> specific ways of doing this or that.
>>> * Allow those who /do/ care to use platform specific methods in
>>> addition
>>> (although I would prefer wrappers for system functions).
>>>
>>> Just my 2ct. I'd fall under the first category.
>>>
>>
>> Exactly the same for me.
>
> Sounds fair to me! And having added the header file
> boost/process/mitigate.hpp recently users have now a choice. Some
> might still not be happy with the options to choose from. But there is
> now a choice at least. :) And as #ifdefs have been mentioned in other
> threads in the previous months: The only use case I'm aware of where
> #ifdefs are ultimately required is waiting asynchronously for child
> processes to exit. For anything else it is possible to write
> cross-platform code (unless someone uses intentionally features which
> are only available on one platform, like file descriptors > 2 on
> POSIX). If anyone runs into a problem here, please let me know and I
> see what I can do about it.
>
> Boris
The main difference in our views is that I'd use the
"abstract-away-all-differences"-variant as default and the platform
specific things as add-on. The current implementation is the opposite.
The mitigate header is not even included by defaul, and hints towards it
sound like a warning, not an encouragement to use it.

IMHO, the main reason for a Process-library in boost would be to have
something that just works with a wide range of compilers and operating
systems. Or, to cite boost file system:

*Portability between operating systems.*
 

  * At the C++ syntax level, it is convenient to learn and use one
    interface regardless of the operating system.
  * At the semantic level, behavior of code is reasonably portable
    across operating systems.
  * Dual generic or native path format support encourages program
    portability, yet still allows communication with users in system
    specific formats.

Or Scott Meyers: "Make Interfaces Easy to Use Correctly and Hard to Use
Incorrectly"

To me that implies: Platform specific stuff only if I really need it.

Regards,

Roland