Re: [boost] [boost.process] 0.6 Redesign

Subject: Re: [boost] [boost.process] 0.6 Redesign
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-04-19 05:32:54

On 2016-04-19 12:23, Klaim - Joël Lamotte wrote:
> On 19 April 2016 at 10:53, Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
> wrote:
>
>> Same here and I believe the majority of people looking for such library
>>> just want to spawn processes in cross-platform contexts. (at least from
>>> memory of
>>> previous boost.process versions reviews)
>>>
>>> (BTW you may need to have a way to tell if a platform cannot launch
>>> another
>>> process? Not sure if a static_if or some kind of no-op would be useful)
>>>
>>>
>> I detect the platform via the preprocessor, i.e.
>> boost/system/api_config.hpp. If you include boost.process without either
>> posix or windows, you'll get an error, saying you have a not supported
>> system api.
>>
>> I'd consider this the right behaviour, since I cannot start any process.
>> Do you have any scenario in mind, where I might want to have a no-op?
>>
>>
>>
> No, like you I prefer the compile-time error in my use cases, but I don't
> know the most usual cases.
> I was considering the cases where you have a function using such library
> and want it
> to do nothing when it can't do anything on the platform, but still not have
> ifdefs.
> I guess just having a different cpp file for non-confirming platforms is
> enough anyway, so compile-time error seems ok.

Can Boost.Process functionality be emulated with 
std::/boost::thread+std::system()? At least partially? Maybe that would 
be a suitable fallback?