26-Jun-2013 18:27, cybervadim пишет:
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.
Here is a chief problem - the assumption that is required to make it
magically work.
Now what I see is:
T arr[];//TLS
//somewhere down the line
arr = ... ;
else{
...
alloctor(myAlloc){
arr = array(filter!....);
}
...
}
return arr;
Having an unsafe magic wand that may transmogrify some code to switch
allocation strategy I consider naive and dangerous.
Who ever told you process does return before allocating a few Gigs of
RAM (and hoping on GC collection)? Right, nobody. Maybe it's an event
loop that may run forever.
What is missing is that code up to date assumes new == GC and works
_like that_.
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?
Yes, but it's horribly broken.
--
Dmitry Olshansky
