On 12 April 2013 14:46, Jesse Phillips <jessekphillip...@gmail.com> wrote:
> It is that time, If you would like to see the proposed std.process include > into Phobos please vote yes. If one condition must be met specify under > what condition, otherwise vote no. > I didn't think I had much of an opinion on std.process, but I just gave it a quick once over and noticed, relating to our recent discussions about flagrant GC usage throughout phobos, that this is riddled with the exact sorts of issues I've been talking about: string[string] is used in the main API to receive environment variables; perhaps kinda convenient, but it's impossible to supply environment variables with loads of allocations. toStringz is used liberally; alternatively, alloca() could allocate the c-string's on the stack and zero terminate them there, passing a pointer to the stack string to the OS functions. String concatenation is rampant! Look at this code to parse the env variables (which are already an AA): foreach (var, val; childEnv) envz[pos++] = (var~'='~val~'\0').ptr; And many many more of the same... This is a lib that spawns a process, I can't imagine why this library should need to allocate a single byte, but it allocates wildly just to perform a trivial pass-through to the OS. This module is no exception either, basically all of phobos is like this, and I'd like to see careful consideration made to these details in the future. I've said before, I sadly have to avoid phobos like the plague. Some modules (like this one) that provide fundamental functionality - not just helper functions - can't be avoided. Requirements for those should be extra strict in my opinion.