Am Thu, 06 Feb 2014 08:40:28 -0800
schrieb Andrei Alexandrescu <[email protected]>:
> >
> > auto gcString = toUpper("test");
> > auto mallocString = toUpper!Malloc("test");
> > ubtye[64] sbuf;
> > auto stackString = toUpper(sbuf[], "test");
> >
> > What's so bad about this?
>
> The issue here is that Phobos functions need to document whether e.g.
> they return memory that can be deallocated or not. Counterexamples
> would be returning static strings or subslices of allocations.
>
> I'm not saying it's not solvable, but it'll take some thinking and
> some work.
That's true. I wonder how common these cases are but slices are
probably the bigger problem here. (OTOH if a function just slices the
input, we'd have to document it but there's no bigger issue)
> > [...] Having an 'application default allocator' or
> > 'thread local default allocator' or 'per function default
> > allocator' will actually hide the allocation strategy and I bet it
> > would cause issues.
>
> I think a crack should be given to the user to install their own
> allocator (per thread and/or shared). Perhaps we can limit that to
> the startup stage, i.e. before any allocation takes place.
If we can make that work then I won't complain. As long as the default
allocator can't be changed at random a point in time most problems
should be solved for a global default allocator.
For per-thread allocators this is difficult: If you allocate in one
thread and free in another how do you make sure you use the correct free
function?
There are some interesting possibilities though: For example we could
add a delegate to object which points to the correct 'free' function.
But then things get complicated if we have to manage the lifetime of the
allocator as well....
> > This is the list of language features which allocate:
> [snip]
>
> I think you forgot AAs.
I had AA literals in the list, but you're right some other AA features
allocate as well. Good you mentioned that, I'll have to detect these
cases in -nogc/-vgc code as well...
However, from a user point of view dcollections (and I hope at some
point std.container as well) provides a nice replacement for all these
operations, except for literals.
>
> > We just have to provide everyone with a way to choose their favorite
> > implementation. Which means we provide public APIs which allow any
> > kind of memory allocation and internally do not rely on automatic
> > memory management (internal allocation in phobos should be done on
> > the stack/ with malloc / made configurable, but not with a GC).
>
> I agree that's a nice goal. But I don't think it's easily attainable.
> The "choose the allocator" part is easy. The harder is choosing the
> reclamation method. There are differences between GC and RC that are
> very difficult to unify under a common API.
>
I'd guess that allocation is actually a bigger issue for those who
are unhappy with the GC right now, but I have no way to prove that ;-)
(Explicit manual freeing is annoying, but possible. But if a function
internally allocates with the GC it can't be used at all).
But you're of course right, getting reclamation right is probably more
difficult and also important.
