Re: [boost] Boost.Process: Formal review request

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;
#endif

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

Regards,

Roland