On 2/6/14, 7:47 AM, Johannes Pfau wrote:
Am Thu, 6 Feb 2014 14:37:59 +0300
schrieb Max Klyga <[email protected]>:
My point is that we should not ruin the language ease of use. We do
need to deal with Phobos internal allocations, but we should not
switch to ARC as a default memory management scheme.
What's with all this finger pointing and drawing battle lines in the
last few days? GC-crowd vs ARC-crowd? Can we please all calm down?
[snip]
Nice. An interspersed point:
I don't think there's anything wrong with the obvious solution: All
phobos functions which allocate take an optional Allocator parameter,
defaulting to GC. The little extra typing won't harm anyone and if you
want to use things like stack-based buffers you'll have to write extra
code and think about memory allocation anyway.
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.
It works for most of phobos, doesn't require
language changes and it's easy to realize what's going on when reading
the code. 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.
So the question then is: what about language feature which allocate
using the GC? Wouldn't we want these to work with any kind of
allocator? Answer: no, because:
This is the list of language features which allocate:
[snip]
I think you forgot AAs.
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.
Andrei
