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-P... Sent from the Boost - Dev mailing list archive at Nabble.com.