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 struct.
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 execute(set_exe("gcc"), set_args({"--version"}); I intentionally changed that, so one could write execute("gcc", "--version"); 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 altogether. 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 incomprehensible.