Boost logo

Boost Users :

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.
>


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net