Re: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]

Subject: Re: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Nat Goodspeed (nat_at_[hidden])
Date: 2011-02-11 08:29:04

On Feb 11, 2011, at 12:54 AM, "Ilya Sokolov" <ilyasokol_at_[hidden]>  
wrote:

> On Fri, 11 Feb 2011 06:01:56 +0500, Boris Schaeling <boris_at_[hidden] 
> > wrote:
>
>> As Boost users we want platform-independent code and convenient  
>> high-level interfaces.

That's my position, yes. If I want a program that will launch a child  
process and read its output on Windows, Mac and Linux, clearly  
"someone" must write three different implementations. I'd prefer to  
use a library that abstracts away the differences. Put differently, a  
library that still requires #ifdefs in my own code doesn't buy me that  
much over the native APIs.

What I want is to write and test my parent-process code once, on one  
platform, with a reasonable level of confidence that I'm not leaving  
nasty surprises for testers on other platforms.

The Python subprocess module gives me an abstraction layer adequate  
for my needs. I would be happy with a Boost.Process library at about  
that level.

>> As C++ developers we want efficient implementations

By the time we've asked the OS to load an executable file plus some  
number of dynamic libraries from disk and resolve references between  
them, a few more cycles in the requesting program hardly seem to matter.

Someone intent on ignoring Knuth's warning about premature  
optimization can, of course, ignore the library and code directly to  
the various native APIs.

>> in my opinion the very different system interfaces are the main  
>> reason. If Boost.Process has platform-independent code only,  
>> developers will complain about the lack of flexibility.
>>
>
> Such library would be practically useless, so it's no-go.

Maybe I'm misreading what you said, but a library permitting a large  
suite of use cases that are meaningful cross-platform is just what I  
need. Again, I offer Python's subprocess module as proof by example  
that this is achievable.

>
>> If Boost.Process provides flexibility with Windows and POSIX APIs,  
>> developers will complain about #ifdefs and writing code twice.
>
> I would call system functions directly, instead.

Provide a way to retrieve platform-specific handles from the high- 
level classes, like retrieving an OS socket from asio. This permits a  
hybrid approach if necessary.

>
>> If Boost.Process supports high-level concepts, developers will  
>> complain about inefficient implementations.

Not me. I'm far more frustrated by the present inability to write  
straightforward cross-platform C++ process-launch code uncluttered by  
#ifdefs.

>
>> If Boost.Process supports only what can be implemented cross- 
>> platform efficiently, the library is so small that it's practically  
>> useless.
>
> No-go.

So remove the efficiency constraint.

>
>> And if Boost.Process supports a compromise like generic code with  
>> extension points, developers from both sides will complain about  
>> not generic and flexible enough.
>
> It's ok ).

I'd rather have something in place that addresses the obvious use  
cases, and argue how to evolve it, than continue writing platform- 
dependent code every time I need to run a child process. That needs to  
be tested and debugged three distinct times, on three different  
computers, with three different IDEs, for each organization with that  
(common!) requirement. Hard to believe Boost still doesn't have this  
library.
>