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

On Feb 11, 2011, at 12:54 AM, "Ilya Sokolov" wrote:

On Fri, 11 Feb 2011 06:01:56 +0500, Boris Schaeling

...

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.