Boost logo

Boost :

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2011-02-08 01:39:02

On Tue, 08 Feb 2011 03:26:57 +0500, Vicente Botet
<vicente.botet_at_[hidden]> wrote:

> 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 think it is enough to assert on valid stream_ids in the create_child()

> The opposite applies to behaviors whose constructor have stream_type
> parameter. These constructors are available only for POSIX, but I don't
> think adding them will change the perception of the user has of his
> application. Couldn't the behaviors provide a uniform interface for these
> constructors? BTW all the constructor taking a stream_type as parameter
> are
> not documented.
> 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.

Those constructors have a sense on windows, no need to ignore anything.

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