Comment #0 by ilyayaroshenko — 2017-01-04T22:35:55Z
Part 1
-------------
std.allocator can be split (virtually) into three parts:
1. OOP Interfaces, theAllocator, constructors and other global variables.
2. Always inlined code.
3. Generic code.
1: OOP code and global variables can be placed in separate module.
2: We have `pragma(inline, true)`. Each function for non-generuc stuff like Mallocator can be marked with this pragma. The size of code seems to be small enough to be always inlined.
3: Generic code should be already fine.
Part 2
-------------
std.allocator uses some functions from `core.*` and maybe `std.*`. They should be betterC too. I don't know how to verify it for all compilers.
Comment #1 by radu.racariu — 2017-10-23T12:05:49Z
+1.
Allocators are missing from betterC mode, and they are a very important improvement over C's malloc/free.
I think scope(xxx) and struct destructors need to work in betterC mode as a mandatory requirement for allocator redesign.
In my opinion they need to be split in 2 : C runtime (core?), and D runtime based - the C runtime based ones should be obviously usable from betterC and ideally the D runtime one should be constructed on the basic blocks provided by the C runtime implementation.
Given the experimental nature of the allocatos package this would be a good time to revisit their design and improve their modularity
Comment #2 by greensunny12 — 2018-02-11T13:44:31Z
From the NG:
> Mallocator contains/contained (is it fixed?) global `instance` member. So it is/was not betterC. This is key betterC bug because Mallocator is the base building blog for almost all possible BetterC allocators. -- Ilya
(https://forum.dlang.org/post/[email protected])
@Ilya: I don't think someone has fixed this already :/
Comment #3 by ilyayaroshenko — 2018-10-11T13:15:15Z