Second Draft: Placement New Expression
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Tue Nov 19 05:05:57 UTC 2024
This still includes typed expressions, which I have some concerns about.
We should not be condoning uninitialized memory as having a type. It can
only cause problems for people. If we stick to ``void[]`` as the input,
we can limit the source to ``@system`` code only.
No double-init bugs please.
The side benefit of this, is the the length is known. If not big enough,
return null.
At the very least we should think about how to make a memory safety DFA
with one layer of indirection support, so not just the variable being
known to be initialized, but what the pointer points to also being
initialized. That would make this a whole lot safer.
> If one desires to use classes without the GC, such as in BetterC,
it's just awkward to use emplace.
Not true, emplace is the easiest part of it as it becomes library code.
No reference counting on classes, lack of ability to mix -betterC with
full D.
https://github.com/ldc-developers/ldc/issues/4779
These are the problems that need solving.
This is how I solved RC classes in -betterC, note that everything is
templated (sigh), and that I have down casting working.
https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/classes.d#L183
> The use of placement new is not allowed in @safe code.
Excellant!
Although I would prefer us to disallow casting to ``void*`` and
``void[]`` also in ``@safe``.
Still too easy to introduce memory unsafe behaviors.
> To allocate storage with an allocator function such as malloc(), a
simple template can be used:
Why not support calling the allocator with the size needed?
```d
struct Allocator {
void[] allocate(size_t);
}
Allocator a;
new (allocator) S;
new (malloc) S;
```
DONE.
More information about the dip.development
mailing list