std.experimental.allocator
IchorDev
zxinsworld at gmail.com
Mon Aug 14 11:14:01 UTC 2023
On Sunday, 13 August 2023 at 16:00:51 UTC, Richard (Rikki) Andrew
Cattermole wrote:
> Yeah you're right Ternary should probably be replaced, although
> amazingly it has never caused problems so far.
>
> But I cannot agree about RAII. Its a valid tool for managing
> lifetimes of memory allocators. Memory allocators must be able
> to store per instance state and that state must not
> accidentally die on you. If it does that is a great way to give
> the user a very bad day.
>
> We are certainly aiming for different things, for instance I
> don't trust my (future) users when it comes to memory safety.
> So they get very well hand held in all aspects. Including
> locking of RCAllocator internally and using RC there.
>
> But internally to API's if you need to optimize you'd use the
> composable allocator structs directly, rather than the
> expensive (in comparison) RCAllocator.
I have complicated feelings about all of this.
The current implementation is a bit confusing, but I think that's
due to somewhat poor documentation that's overenthusiastic to
explain the complicated inner-workings, which would only matter
to you if you want to build your own allocator. For an average
user, the API could be explained as "malloc + free, except
they're type-safe and take a custom allocator as an argument":
```d
auto x = make!Type(someAllocator);
dispose(someAllocator, x);
```
I agree with ryuukk_ that it should really be a `core` submodule,
and obviously work with BetterC (but maybe still using exception
throwing if we're being a bit forwards-looking).
`std.experimental.allocator.building_blocks`—and some other
modules like it—have a lot of good code that I think shouldn't
just be thrown out:
https://dlang.org/library/std/experimental/allocator/building_blocks.html
I agree that the "interfaces" of the allocators should be re-done
without `class` or `interface`. Some of the interface functions
are explicitly optional, which would work better with a `struct`
and function pointers. For the non-optional stuff, that's an
annoyance...
More information about the Digitalmars-d-learn
mailing list