On Sun, 6 Nov 2016 09:30:18 +0100
Klemens Morgenstern
Am 06.11.2016 um 01:39 schrieb Lee Clagett:
On Sat, 5 Nov 2016 17:15:58 +0100 Bjorn Reese
wrote: I'm glad you brought this up - I think Niall did as well - if you look at the constructor documentation for `process::child` it is very bare. And I am not sure how to easily describe how to use it. I think maintainability is going to be difficult without a more strict contract of expected arguments and behavior. That is because it is one of the three launch functions, but their are actually quite clearly defined. You either pass a known type that will be intepreted as some property (i.e. std::string->args) or you
[...] [...] [...] pass a property directly, i.e. args+="Value". That is quite clear, but it is extensible, hence the list of actually allowed types are written in the reference at the properties, not in a central list.
Is the following clear: bp::child("foo", "arg1" bp::stdout < bp::null, bp::args="arg2"); Does the last constructor argument clear all `argument properties` used by the child? Would this try to invoke process "arg2"?
@Bjorn: That's the syntax you would get if you used rvalue qualifications, as you proposed. [...] [...] [...]
Again, I think Niall proposed something similar (callable). Also, I do not think partial evaluation support is necessary in boost::process - `boost::fit` (which I hope/think will be a boost lib) could partially bind command arguments or even std::bind. The syntax would be different, but once its a callable its much more flexible:
auto with_jar = std::bind(child("java"), "-jar", "antlr4.jar", _1);
Now `with_jar` requires a single string argument to be invoked, and invoking it executes the process and returns a handle to that process. And and why is that better then the current way of doing things?
auto antlr = [](const std::string & g4) {return child("java", "-jar", "antlr4.jar", g4);}; //or add an redirection: auto antlr_p = [](const std::string & g4, pipe &p){return child("java", "-jar", "antlr4.jar", g4, std_out > p, std_err > null);};
I was responding to Bjorn who suggested some kind of argument builder/binder. I didn't think it was necessary based on the rest of his proposed syntax. Lee