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.
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.
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 - 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?