On Friday, 12 April 2013 at 20:52:55 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 16:32:37 -0400, Tove <[email protected]>
wrote:
On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 15:26:12 -0400, Tove <[email protected]>
wrote:
So for the most convenient/common case, you want to add an
allocation?
with the original proposal there is one anyway...
I meant add an additional allocation to what is there. There
needs to be one allocation to collect all the variables into
one long string (on Windows), and with your suggestion, it has
to go through an intermediate "key=value" format.
But with my suggested approach you could create many processes
reusing the same env... only paying the conversion/allocation
cost once(outside of the loop).
This would be attractive. But I still want a indexable object.
Having to generate a=b strings is awkward.
It could be something that does the right thing on POSIX
(generate "a=b" under the hood) or Windows (Probably can cache
the generated environment string).
-Steve
Hmhm, I see your point. Could our custom indexable object have
'alias this' to an 'union env'? which is the in param to the
process api?
