On Wed, 16 Feb 2011 15:57:06 +0100, Jeff Flinn
[...]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:
Thanks, but I think you misunderstood me. What I've been trying to understand and why I asked my questions is whether you think we need POSIX- and Windows-classes and -functions which would require a library user to use conditional compilation. I thought that this is what you had proposed (eg. with a POSIX and Windows executor)? Or did I misunderstand? I ask as a final decision whether we want library users to choose between a generic API, a Windows API and a POSIX API via conditional compilation could at least make future discussions easier. Even though I think that the majority wants one generic non-system-specific API in Boost.Process, outlining the reasons for or against it hopefully avoids going through all of this a few more times again in the future (especially as jumping around between these options would always require lots of changes in Boost.Process). Boris
[...]