
Boris Schaeling wrote:
On Wed, 16 Feb 2011 15:57:06 +0100, Jeff Flinn
wrote: [...]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
Sorry, I am having a hard time understanding the questions.
understand and why I asked my questions is whether you think we need POSIX- and Windows-classes and -functions
Yes.
which would require a library user to use conditional compilation.
The former does NOT require the latter.
I thought that this is what you had proposed (eg. with a POSIX and Windows executor)? Or did I misunderstand?
In the example code I've previously posted there is NO conditional compilation in the user's code. There IS conditional compilation in the library extension code. I've attached the latest zip imple
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).
I'm not sure what exactly is being asked here. Are you asking(all reviewers) which of the following approaches are acceptable for providing library extensions? 1) use platform specific api to provide extensions providing access to ALL platform capabilities 2) use platform independent api to provide extensions limited to only those capabilities common to all platforms Thanks, Jeff