Boost logo

Boost :

Subject: Re: [boost] Boost.Process: Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2012-12-14 03:30:39

On 2012-12-14 00:26, Boris Schaeling wrote:
> On Thu, 13 Dec 2012 12:23:45 +0100, Roland Bock <rbock_at_[hidden]> wrote:
>> [...]The mitigate header is not even included by defaul, and hints
>> towards it
>> sound like a warning, not an encouragement to use it.
> That's correct - exactly what I intended. :)
> What I try to get across is that there is a different quality of
> service. On the one hand there are functions like execute(),
> wait_for_exit() or the various initializers. They are intrinsic to
> Boost.Process, and I as the library maintainer guarantee that they
> work as documented or I'll fix it. On the other hand there are helpers
> in the mitigate header which maybe do what you need - without an exact
> definition what this should be nor a guarantee from my side that this
> will always be the case.
> There is for example the typedef boost::process::pipe_end. Depending
> on the platform it's a different Boost.Asio class. These Boost.Asio
> classes have a couple of member functions which have the same
> signature on all platforms. That's what makes it possible to write
> cross-platform code to initiate asynchronous operations. But
> boost::process::pipe_end doesn't guarantee that you will never need to
> use #ifdefs. For example, it is possible that you want to call a
> member function which exists only on one platform.
> From Boost.Process' point of view the ideal solution would be if
> Boost.Asio provided a cross-platform type for file descriptors/Windows
> handles. As this type doesn't exist Boost.Process makes a best effort
> - but no more.
Got it, here's what I'd suggest (not being very knowledgeable about
Asio's file descriptor / windows handles):

a) File an asio bug / feature request (guess you already did that :-) )
b) Write a wrapper that offers only the common methods. This wrapper
would become a typedef (or is eliminated completely) once the platform
independent asio type is available

With b) you would be able to offer a platform independent pipe_end. And
if someone really needed a special feature that isn't available in the
platform independent thingy, he could then use the current version

#if defined(BOOST_WINDOWS_API)
  typedef boost::asio::windows::stream_handle pipe_end;
#elif defined(BOOST_POSIX_API)
  typedef boost::asio::posix::stream_descriptor pipe_end;

This would have no impact on current users of the library, but it would
make it much easier for new users.



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