The new std.process is ready for review

Lars T. Kyllingstad public at kyllingen.net
Tue Feb 26 11:33:14 PST 2013


On Tuesday, 26 February 2013 at 18:24:08 UTC, Steven 
Schveighoffer wrote:
> On Tue, 26 Feb 2013 12:03:51 -0500, Lars T. Kyllingstad 
> <public at kyllingen.net> wrote:
>
>> On Tuesday, 26 February 2013 at 16:45:08 UTC, Steven 
>> Schveighoffer wrote:
>>> On Tue, 26 Feb 2013 11:09:48 -0500, Lars T. Kyllingstad 
>>> <public at kyllingen.net> wrote:
>
>>>> spawnProcess(["prog"]);
>>>
>>> That allocates.  I don't like that requirement.
>>
>> 'scope string[] args' should tell the compiler not to allocate.
>
> That's not how it works.  The expression [<anything>] allocates.

Isn't that just a shortcoming of DMD?  I thought 'scope' was all 
about avoiding such allocations.


>>> At the very least there should be version which takes a 
>>> simple string, an easy thing to wrap:
>>>
>>> auto spawnProcess(string program, File stdin, etc...)
>>> {
>>>   return spawnProcess((&program)[0..1], stdin, etc...);
>>> }
>>>
>>> We should also consider a variadic solution.  In tango, 
>>> things were done with an object, so the arguments were set 
>>> via one method/constructor, and the options (stdin, stdout, 
>>> etc) were set via another.  This allowed the great API of
>>>
>>> setArgs(string[] ...)
>>>
>>> Which supports
>>>
>>> setArgs("progname", "arg1", "arg2")
>>>
>>> and
>>>
>>> setArgs("progname arg1 arg2".split())
>>>
>>> without extra allocation.  However, we have two conflicting 
>>> parts to spawnProcess that would be optional -- the variadic 
>>> arg list, and the optional redirected handles and 
>>> configuration.
>>>
>>> We could just go full-bore variadic...
>>
>> I'd rather not.
>
> Did that apply to all the statements above, or just the 
> variadic part?

The variadic part.  (And the Tango-like object part, though that 
didn't read like a suggestion.)  A single-string version of 
spawnProcess() is OK with me, in combination with either of:

   spawnProcess(string, string[], etc.)
   spawnProcess(string[], etc.)

Lars


More information about the Digitalmars-d mailing list