Vote for std.process

Steven Schveighoffer schveiguy at yahoo.com
Fri Apr 12 13:24:05 PDT 2013


On Fri, 12 Apr 2013 15:26:12 -0400, Tove <tove at fransson.se> wrote:

> On Friday, 12 April 2013 at 15:43:27 UTC, Steven Schveighoffer wrote:
>> On Fri, 12 Apr 2013 04:14:15 -0400, Manu <turkeyman at gmail.com>
>>> I'd use string[].
>>
>> You mean with format "a=b"?  I suppose that's possible, though horrible  
>> to work with before passing in.  Plus what happens if you have ["a=b",  
>> "a=c"] ?  AA's prevent these kinds of mistakes/contradictions.
>>
>
> I prefer Manu's idea with the API accepting string[], it's closer to the  
> native format.

That's great for the library on POSIX systems, but for the user, it's not  
as straightforward.  One must construct "x=y" strings instead of setting x  
to y.  Unless you are using literals, this involves an allocation anyway.

Also, this is not the native format on Windows which passes the  
environment in one large string delimited by nulls.

>
> Then you could simply provide a convenience conversion from a map...
> ex env!["foo" : "bar"] which would convert it to ["foo=bar"].
>
> This also has the added benefit of being self documenting(considering  
> the lack of named parameters).

So for the most convenient/common case, you want to add an allocation?

> But most importantly So the user has a free choice of constructing the  
> env parameter manually in the most efficient way or using the lazy  
> convenience function.

I think the best suggestion so far is to allow a templated version for  
which you can provide an opIndex method, and a possible toEnv method  
(versioned for both Posix and Windows of course).  Then you have the power  
to avoid allocation as much as possible.  At the moment with AA's being  
the interface, we have no possibility to avoid allocation, and I  
understand that point.  But I don't want to eliminate that case or make it  
specifically more inefficient.

-Steve


More information about the Digitalmars-d mailing list