CTFE and minimizing the GC

Stefan Koch via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 31 13:30:16 PDT 2016


On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:
> 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?

For quick fix std.allocator has to be fitted with a if(__ctfe) to 
detect usage at CTFE and use CTFEable allocation instead.


More information about the Digitalmars-d mailing list