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-09 02:57:18

Ilya Sokolov-2 wrote:
> On Wed, 09 Feb 2011 04:23:55 +0500, Vicente Botet wrote:
>> Boris Schaeling wrote:
>> [snip]
>>>> [...]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.
> AFAICS, you proposed something else, not that 'these constructors
> must be protected...'

You're right I didn't do it. I was mixing with what I said for other
constructors that have native types as parameters.

Sorry for the noise.

How can I create a process instance? From where I can get the pid_type or
the handle? I think that these constructors must be protected.

>From where I can get the constructor pid_type ? I think that this
constructor must be protected and the create_child function declared friend.


Shouldn't the public constructor from a native_handle be reserved to the


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