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

Subject: Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-16 09:57:06

Boris Schaeling wrote:
> On Mon, 14 Feb 2011 15:29:57 +0100, Jeff Flinn 
> <TriumphSprint2000_at_[hidden]> wrote:
> 
>> [...]In the attached zip, I've updated the windows executor 
>> implementation to
>> [...]The posix executor would remain string agnostic.
> 
> Can you describe when I would like to use the Windows or POSIX code of 
> the library? 

Only when you need to.? I'm not sure what you're asking.

 > I ask as this code has obviously not the goal of being
> platform-independent. What's then the goal?

It does have the goal of being platform-independent and is portable for 
a large class of usage patterns. I've now filled in most of the 
interface on the POSIX side that I've shown for windows, and it 
compiles. I'll post it later today. I've compiled on MSVC8 and gcc 4.0.1 
  from XCode 3.1.2 on Mac OSX 10.5.8.  This effort uncovered some 
missing boost iostreams functionality to easily get a 
file_descriptor_source/_sink from stdin/stdout/stderr that is worked 
around by #define fileno _fileno on windows in the process config file. 
That being said, I'm starting to see several areas of commonality that 
could be factored out into a few template classes.

> - If I want to use system-specific features, I could access system APIs 
> directly (as I think I have to use #ifdefs anyway?).

Yes you could access API's directly, In my view the utility of the 
executor/initializer framework makes process invocation easier, more 
robust and more testable. Our development group's strategy for platform 
dependencies is to avoid #ifdef's. Platform dependent code is abstracted 
and typically the dependent implementation is placed in a 
xxxPlatformImpl.cpp. The ide/build system then includes the appropriate 
file for the platform. Platform dependent headers are kept in separate 
directories with the appropriate path being added to the compile include 
paths command.

> - If it should be easier to create child processes, the Windows or POSIX 
> code is either a subset or a reinvention of the system API? Then I 
> either have to call system APIs at some point again (if I need access to 
> more features) or I have to learn a second API which does the same as 
> the system API? Furthermore, the rationale for the design would need to 
> depend on system APIs and not on generic code (for example a generic 
> executor doesn't necessarily mean there should be a Windows and a POSIX 
> executor).
> 
> - If I want to easily switch from generic to system-specific code and 
> the library wants to help me: Where is the right trade-off between 
> Windows and POSIX code which is as similar as possible to generic code 
> and Windows and POSIX code which provides access to all 
> platform-specific features a developer could be interested in?

An example of using the executor/initializer framework to support 
platform dependent behavior came up when our Windows/Mac gui app needed 
to run a third-party non-gui app that opens a curses based window for 
user interaction. The windows os also opens a console window by default 
which was confusing to our users. So we created a no_console initializer 
that set the appropriate visibility flags on windows and does nothing on 
Mac/POSIX. We placed the platform specific versions in separate files. 
But for exposition you could have this single header:

no_console.hpp
--------------
#pragma once

#include <boost/process/initializer.hpp>

struct no_console : public initializer
{

#  if defined(BOOST_WINDOWS_API)

    void pre_create(executor& e)
    {
       e.m_startup_info.dwFlags     |= STARTF_USESHOWWINDOW;
       e.m_startup_info.wShowWindow  = SW_HIDE;
    }

#  endif

};

The client code uses it like:

bp::executor().exec(fus::make_vector
( bp::paths("some.exe")
, bp::args ("some arg")
, ...
, no_console()
, ...
));

Hope that answers some of your questions.

Thanks, Jeff