Subject: Re: [boost] [boost.process] 0.6 Redesign
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-04-19 14:51:52
Am 19.04.2016 um 20:08 schrieb Niall Douglas:
> On 19 Apr 2016 at 13:34, Klemens Morgenstern wrote:
>> Because it absolutley requires
>> metaprogramming and it is the only elegant choice. On Windows you have a
>> function overblown with parameters, making it unreadable. On Posix you
>> have to call several functions to get a process up. And my design has a
>> variadic function, which allows you to pass only the arguments you need.
> A freeform constructor with tagged parameters is absolutely right for
> when the parameters can be extended by third party code. Here though
> parameter types are completely known, so the appropriate design for
> when there are too many parameters and/or you'd like to name them is
> to pass a tagged tuple aka a struct.
> The choice to use metaprogramming should always confer an absolute
> design win over all other design alternatives given the increased
> compile times, memory usage, brittleness and other factors.
> Metaprogramming is very much not free of cost. It should be used as
> sparingly as possible in publicly facing library APIs.
> In particular I find Process' use of a freeform constructor
> gratuitous given the much simpler close substitutes like passing a
Well, it doesn't seem like we'll agree any time soon, but that's imho
the beauty of open-source. If you have any design for a process library,
I would be very much interested in it.
Btw: boost.process 0.5 only allowed initializers to be passed to the
execute function, i.e. you had to write
I intentionally changed that, so one could write
because I find this much more intuitive (i.e. design win). This allows
more parameter to be passed, like std::error_code or
boost::asio::io_service. And unlike your proposed "make everything
async" solution, you only pay for it, if you use it. I could add an
exe_args initializer, so you can get rid of the initializer building
I personally consider the overhead reasonable, at least in comparison to
forcing to much structure onto the user. And considering the amount of
possible parameter you can pass, I'd think a struct would be rather
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk