Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-06 19:46:42
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:
while this would look sort of overdone in the same context:
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk