Boost Users :
Subject: Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-10 08:48:57
I've used the process library as a replacement for Qt's QProcess(which
interfers with the main event loop in our application on Mac OSX). We
were able to make boost process work across Windows and Mac OSX, but did
not have that sense of satisfaction at the end that usually comes with
using most boost libraries.
I do not think the library should be accepted into boost for the
Still had to create wrapper function and classes and use ifdef's to
handle platform dependencies in client code.
Stung multiple times when passing a relative path when setting the
working directory on unix systems.
Different semantics regarding success/failure of CreateProcess/exec.
Lack of synchronicity when launching.
Lack of launch error reporting.
Replication of existing boost library functionality, and functionality
that better belongs to other libraries.
Lots of additional 'stuff' in the header implementing create_child.
Pay for process handles even when not used.
Overly complex io specification.
Customization points lack access to many of the required Windows
Implementation is obfuscated by all of the ifdef'd platform dependencies
within a single function.
Lack of separation of concerns in create_child
The monolithic code lacks ability to properly unit test components.
I started with a fresh slate over the last couple of weeks and have an
initial high level design of the process launch part that alleviates
many of the above problems. It's key aspect is that the stock facilities
themselves are built using the same customization points that client
code can use to extend the library. I'm attaching some initial high
level documentation as a pdf, and a rough initial implementation in a
zip file. This is still very preliminary, but I thought it important to
add to the discussion now.
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