Vote for std.process

[Manu]

On 12 April 2013 18:34, Johannes Pfau <nospam at example.com> wrote:

> Am Fri, 12 Apr 2013 17:04:08 +1000
> schrieb Manu <turkeyman at gmail.com>:
>
> >
> > 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.
> >
>
> Most (GC) allocations could be fixed without breaking the API. I can
> see 2 places where the API forces _GC_ allocations:
> * string[string]
> * thrown Exceptions are allocated with the GC
>
> There is no simple solution for these. Maybe we'll have a hashtable in
> the standard library at some point which will allow to use custom
> allocators. Then std.process could use these. Exceptions require some
> thinking. You can of course allocate them using any allocator, but
> freeing them is difficult...
>

Exceptions are exceptional, I don't think that's an issue.
the string[string] in the api is guaranteed garbage, and will never be
changed. What's the advantage of using an AA in this case?

If you want to get rid of all (not only GC) allocations, there's another
> issue: As D strings are not zero terminated we'll always have
> allocations passing those to C code.


They are being passed through to a C function that doesn't retain the
pointer; they can be allocated on the stack.

Maybe we should have a cstring
> type in phobos which would just be a string which is guaranteed to be
> zero terminated.
>

Maybe, although the point here is to wrap up and hide the C API, so that's
not useful here. A helper in phobos for allocating a (c)string on the stack
may be useful...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130412/2c776f9d/attachment.html>