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