std.allocator needs your help
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Sep 23 10:16:40 PDT 2013
On 9/23/13 10:01 AM, deadalnix wrote:
> On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu wrote:
>> Hello,
>>
>
> First of all, awesome !
>
> Now the meeeeh part.
>
> I really think the it thing is not good. I don't think it is desirable
> or necessary. We should get rid of it.
The singleton allocator "it" is instrumental for supporting stateful and
stateless allocators with ease. It took me a few iterations to get to
that, and I'm very pleased with the results. I think it would be
difficult to improve on it without making other parts more difficult.
> You can't deal with ubyte[] like that, that is incorrect in regard to -
> unimplemented - aliasing rules. Allocator should deal with void[] .
I think I'll do that.
> What you call safe really isn't. Allocate something on the GC, store a
> pointer on a custom allocated location, collect, enjoy the memory
> corruption.
I don't understand this. There are no pointers at this level, only
untyped memory. The main chance of corruption is to access something
after it's been freed.
> All operation are safe according to your proposal.
No, for most allocators freeing and reallocating are unsafe.
> Allocation can only be safe if the GRAND MASTER GC is aware of it.
I don't think so.
> You proposal allocate shared memory.
No. It allocates unshared memory off of a shared or unshared allocator.
The memory just allocated is as of yet unshared for the simple reason
that only one thread has as of yet access to it.
> This is common in C/C++ world as
> memory is shared by default, but shouldn't be in D. It is highly
> desirable to allocate with different methods for different type
> qualifier. How does your design adapt to that ?
The typed allocators will have distinct methods for shared and unshared
allocation. Even at this level it's possible to design an allocator that
allocates in different ways with a shared vs. an unshared allocator
object (overload on shared). So far I've only designed non-shared
allocators, or wrap those that are already shared (malloc and new).
> Finally, we got to decide how these basics block are used to form typed
> allocators, and interact with language constructs.
Sure. Again: I describe the Otto cycle and you discuss how to paint the
road.
Andrei
More information about the Digitalmars-d
mailing list