Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Roland Bock (rbock_at_[hidden])
Date: 2012-08-26 12:46:08

On 2012-08-25 17:27, Boris Schaeling wrote:
> On Tue, 21 Aug 2012 10:06:49 +0200, Roland Bock <rbock_at_[hidden]> wrote:
>
>> [...]b) Hmm. Not following. Why not use the null sink from
>> boost::iostreams?
>> You can create a stream from it that does what I would expect from
>> redirecting to /dev/null: Discard all data.
>
> Indeed it would be nice if you could write something like:
>
> execute(
>   run_exe("test.exe"),
>   bind_stdout(boost::iostreams::null_sink())
> );
>
> Unfortunately null_sink doesn't open a file descriptor or HANDLE (it's
> just that its read and write functions are no-ops). And without a file
> descriptor or HANDLE there is nothing to inherit by the child process.
> That's why I had to open /dev/null or NUL myself in the example (and
> had to use #ifdefs ;).
OK, got it. You need the handle... As you suggest below, I'd prefer a
utility method to provide the file handle to /dev/null or NUL.[...]I am
hoping for a way that lets 95% of the users write platform
>> independent code without the need for #ifdefs.
>
> So far I'm already happy that for 95% of process related tasks I can
> write platform-independent code. I'm looking at this other 5% where I
> have to use #ifdefs as a mild but bearable annoyance. :)
As written before: The library is pretty cool already in my eyes. I just
think that a few more improvements with respect #ifdef reduction in the
library users' code would make it a great library, fit for boost.

> To move somewhat forward with Boost.Process: I (or others if they like
> - just send me an email) will create some utility classes and
> functions which are not truly mapping existing concepts on all
> platforms and put them into their own namespace (and probably header
> file). They would provide the convenience some people ask for. And
> they would also make it clear that they don't fit perfectly in with
> the rest of the library and can have quirks.
IMHO, that sounds like a very reasonable plan to proceed. Personally I
hope, that the utility stuff will eventually move into the main
namespace, though.

Best regards,

Roland

>
>>       o I am not sure about the #ifdef in the code. Maybe somebody has a
>>         nice idea, otherwise I would just let leave it as it is.
>
> I agree. Even an utility class wouldn't probably be easy to use.
>
> Boris
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost