Am 07.11.2016 um 01:14 schrieb Gavin Lambert:
On 6/11/2016 21:30, Klemens Morgenstern wrote:
The core of my proposal is to keep attributes separate from arguments (granted, this was not explicitly mentioned before.) [...] 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.
I think perhaps the request is to remove the magic inferring of purpose for external argument types (eg. that passing a std::string represents an argument... sometimes) in favour of making this explicit (arguments can only be passed via "args", either constructed inline or prepared beforehand and passed in.
By extension, probably the only types that the launch functions should accept are the explicit "named parameters" helper types defined in Boost.Process (or compatible extensions). That's what boost.process 0.5 did, I extended that (in an also -
I didn't understand it that way, especially since he Bjorn mentioned boost::thread. I'm a bit tired of this discussion, and Boris explained very well, why the initializers-approach was chosen. As far as I understand it he considers everything but args as attributes and wants them all crammed into one type (or something like that) which would be a horrific mess. I should know, I tried to build somethinke like that (based on boost.process), just two ours ago - it doesn't work for a proper process library, there are just too many properties to a process. Also the "sometimes" is clearly defined: the first string if not after an exe initializer will be interpreted as the argument for exe - unless there's only one, then it's a cmd. theorectically - extensible way), because I really like this syntax: bp::system("gcc","--version"); while this would look sort of overdone in the same context: bp::system(exe="gcc", args={"--version"}); This would also require additional explicit arguments, which are completely unnecessary, since the type can only be used in one way, those would be: group, asio::yield_context and asio::io_service.
This might be slightly annoying in the case of the child process executable path, though. I don't know whether it'd be worthwhile making an exception for that case or not.
I don't understand the problem with allowing both in the first place, but you're mentioning why I added that feature. So why only for the exe?