2 ms·
I've seen this type of API design in C before, but not with a context. I'm curious where HAMT would get the ctx instance to pass to hamt_malloc in this design?
by hgs3 3y ago
I've seen this type of API design in C before, but not with a context. I'm curious where HAMT would get the ctx instance to pass to hamt_malloc in this design?
- kazinator 3y agoIf the macro doesn't use the argument, it doesn't have to exist. Currently the code does use macros, e.g. mem_alloc(h->ator, size). Firstly, I'd hide the detail of how the allocator is derived from h into the allocator wrapper routines and just make it mem_alloc(h, size). It's mem_alloc which can do h->ator. Now the nice thing is that h always exists. So even mem_alloc ignores the first parameter, we don't have to pass something fictional as an argument: #define mem_alloc(h, size) malloc(size) then remove the h->ator and related cruft. Someone who needs a context for their allocator can hack that in. By the way, if you're going to have allocator providers, you want: #define mem_alloc(h, size) h->ator->alloc(h->ator, size) ^^^^^^^ and not: #define mem_alloc(h, size) h->ator->alloc(size) like the code has it now. Thou shalt not define a C callback interface without a context pointer. Without a context pointer, you cannot have an allocator module where you can bind different allocator arenas to different objects.