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.
Vicente

"
[process::process]
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.

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

[handle]

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

Vicente

-- 
View this message in context: http://boost.2283326.n4.nabble.com/Subject-Formal-Review-of-Proposed-Boost-Process-library-starts-tomorrow-tp3263607p3296707.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk