Was: Re: Vote for std.process

[Lars T. Kyllingstad]

On Friday, 12 April 2013 at 11:37:14 UTC, Regan Heath wrote:
> I've moved this to another thread to allay complaints.

Thanks!

I completely agree that if code can be made more performant 
without a significant increase in complexity, then we should do 
so.  While it is mostly (but not entirely) irrelevant in the 
context of std.process, it is a problem that should be tackled in 
Phobos as a whole.  Several things could/should be done:

It would be nice to have some sugar on top of alloca(), the use 
of which is usually considered bad practice.  Someone 
(bearophile?) once suggested static arrays whose length is 
determined at runtime, which would be a great addition to the 
language:

     void foo(int n)
     {
         int[n] myArr;
         ...
     }

Furthermore, we need to get the allocator design in place.  In 
SciD, I use David Simcha's region allocator to allocate temporary 
workspace, and it works really well.  The only times I use 'new' 
is when I need persistent memory (e.g. for a return value) and 
the user-supplied buffer is too small.  Phobos would greatly 
benefit from doing this too.

Finally, an example from the new std.process which got some heavy 
criticism in the other thread:

     envz[pos++] = (var~'='~val~'\0').ptr;

I have been operating under the assumption that the compiler is 
smart enough to make the above a single allocation.  If it isn't, 
I would consider it a compiler issue.

That said, I am aware that std.process could be improved in some 
places.

Lars