why allocators are not discussed here

cybervadim vadim.goryunov at gmail.com
Wed Jun 26 07:27:02 PDT 2013


On Wednesday, 26 June 2013 at 14:17:03 UTC, Dmitry Olshansky 
wrote:
> Awful. What that extra syntax had brought you? Except that now 
> new is unsafe by design?
> Other questions involve how does this allocation scope goes 
> inside of functions, what is the mechanism of passing it up and 
> down of call-stack.
>
> Last but not least I fail to see how scoped allocators alone 
> (as presented) solve even half of the problem.

Extra syntax allows me not touching the existing code.
Imagine you have a stateless event processing. That is event 
comes, you do some calculation, prepare the answer and send it 
back. It will look like:

void onEvent(Event event)
{
    process();
}

Because it is stateless, you know all the memory allocated during 
processing will not be required afterwards. So the syntax I 
suggested requires a very little change in code. process() may be 
implemented using std lib, doing several news and resizing.

With new syntax:


void onEvent(Event event)
{
    ScopedAllocator alloc;
    allocator(alloc) {
      process();
    }
}

So now you do not use GC for all that is created inside the 
process().
ScopedAllocator is a simple stack that will free all memory in 
one go.

It is up to the runtime implementation to make sure all memory 
that is allocated inside allocator{} scope is actually allocated 
using ScopedAllocator and not GC.

Does it make sense?


More information about the Digitalmars-d mailing list