Boost logo

Boost :

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-02-08 18:23:55

Boris Schaeling wrote:
> On Mon, 07 Feb 2011 23:26:57 +0100, Vicente Botet
> <vicente.botet_at_[hidden]> wrote:
> Hi Vicente,

Hi Boris,

>> I want to discuss here of how transparent would be the user code to be
>> able
>> to use non portable extension with the current interface. The way
>> extensions
>> are provided means that a user needs to use the BOOST_POSIX_API,
>> BOOST_WINDOWS_API in his own code when he uses an extension. Could the
>> documentation include some explicitly examples.
> there is an example at
> (for POSIX) and at
> (for Windows). If the documentation doesn't refer to them clearly I'll
> have to improve it. :)

I was looking for an example of portable code that uses the two functions.
That is merge the two examples in one.

>> [...]Note that these setup functions are called on a different context
>> either on
>> the child either on the parent process, but both will be assigned to the
>> same context field.
> True (and it's good that you noticed; that makes me think the
> documentation is not that bad :).
>> Any setting of the ctx.streams with fd >2 should be protected
>> ctx.streams[3] = ...
>> While the preceding code doesn't have any sens under WINDOWS, the library
>> don't provide an interface that forbids it, but the current
>> implementation
>> just ignore it. I'm not sure if this is good in this case as the
>> application
>> could not work in the same way in POSIX or WINDOWS systems. If the class
>> stream_id I proposed in this thread is used as domain of the map, the
>> code
>> will not compile as a stream_id cannot be constructed from fd>2 on
> I have to read your other email still. The operator[] is rather new
> though. We had three get functions before to access the handles for stdin,
> stdout and stderr of the child process. I had argued that these are the
> only cross-platform streams. However the counter-argument was that there
> was no way to pass fds > 2 to a child process on POSIX - not even with an
> extension point. Developers would need to look for another library to do
> that. So we tried to create an interface which would make sense for
> Windows developers and would provide developers on POSIX the flexibility
> they need. That's how we got here.

Thanks for the exlanation. I was aware by reading the thread of
september-october :)

>> [...]Instead of just defining them for POSIX
>> #if defined(BOOST_POSIX_API)
>> pipe() : stype_(unknown_stream) { }
>> pipe(stream_type stype) : stype_(stype) { }
>> #endif
>> You can add the respective constructors for WINDOWS, even if the
>> parameter
>> is completely ignored.
>> #if defined(BOOST_WINDOWS_API)
>> pipe() { }
>> pipe(stream_type /*stype*/) { }
>> #endif
>> The same applies to all the behaviors using stream_type.
> The use case would be to create a stand-alone pipe outside of
> Boost.Process? If so I wonder whether we should (additionally?) provide
> something else than stream behaviors. They are pretty much tailored for
> Boost.Process. I'm fine with making the constructors available on all
> platforms. But it's not nice that you get a stream_ends object with a
> parent and child end when you actually want to create a pipe with a read
> and write end?

Yes this exactly why I was proposing that these constructors must be
protected and used only by the implementation as the correct use can be
possible as undocumented. Read on the other post.

>> Could a table of extension be included on the documentation?
> Do you mean extension points? Or sample programs like the two above?

Extension points. As Doxigen don't allows to show it in the synopsis, a
table showing the specific extensions points will help.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at