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-17 09:20:15

Boris Schaeling wrote:
> On Wed, 16 Feb 2011 15:57:06 +0100, Jeff Flinn 
> <TriumphSprint2000_at_[hidden]> 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