Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-02-07 17:26:57

Hi,

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.

The interface of the setup callback is different so the user will need to
define two possible setup functions.

#if defined(BOOST_POSIX_API)
void setup() {
 ...
}
#elif defined(BOOST_WINDOWS_API)
void setup(STARTUPINFOA &sainfo) {
 ...
}
#endif

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. 

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

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.

Could a table of extension be included on the documentation?

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