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.
I beg to disagree. Passing a struct to a function (and I assume passing a struct by constant reference) is not the best of all choices. It is cumbersome, inflexible, and not extensible. Why do you try to get away from the API Boost.Process V0.5 provides in the first place? Do you have a rationale for this? I found that API to be very nice, concise, easily extensible (even by the user), and to be trivial for trivial use cases. All of which are signs of a good API design.
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.
Sorry to ask, but what is a 'freeform constructor'? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu