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
>>> specific ways of doing this or that.
>>> * Allow those who /do/ care to use platform specific methods in
>>> (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.
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
Or Scott Meyers: "Make Interfaces Easy to Use Correctly and Hard to Use
To me that implies: Platform specific stuff only if I really need it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk