CTFE and minimizing the GC
Jacob Carlborg via Digitalmars-d
digitalmars-d at puremagic.com
Mon Oct 31 13:23:13 PDT 2016
One of the big features of D and a feature that is show cased is CTFE.
The regex module and the PEG parser generator are projects that are
often mentioned when talking about what CTFE can do.
One of the, or _the_, major goal now for D is to reduce the dependency
on the GC in the standard library.
These two features/goals don't mix very well together. For CTFE,
basically the only way to allocate memory is using the GC or stack
allocated memory.
One way to minimize the dependency on the GC is to use allocators, i.e.
std.experimental.allocator. It's understandable that an allocator that
uses malloc/free under the hood doesn't work at CTFE. But there's both a
GC allocator and a stack allocator, which in theory sounds like they
could work. One could imagine a function taking an allocator as a
policy, using a custom well optimized allocator that will be used at
runtime. But when the function is used at CTFE, pass in the GC allocator
instead. Unfortunately neither the GC allocator nor the stack allocator
work at CTFE.
Using StackFront at CTFE will give you the following error:
region.d(323,20): Error: null - null cannot be interpreted at compile
time: cannot subtract pointers to two different memory blocks
Trying to use GCAllocator at CTFE will give you:
Error: static variable instance cannot be read at compile time
Or trying to create your own instance to bypass the above error:
memory.d(368,25): Error: gc_malloc cannot be interpreted at compile
time, because it has no available source code
Is this something that the D core team is aware of and is planning to
address?
Is it possible to have an allocator fulfilling the allocator interface
at the same time works at CTFE?
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list