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

Boris Schaeling wrote:

On Mon, 14 Feb 2011 15:29:57 +0100, Jeff Flinn 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 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