digitalmars.D.learn - Intelligent Scope Hierarchy
Hi, I'm new to D and stumbled on the new allocators thread. In
the help there is code like
auto buffer = Mallocator.it.allocate(1024 * 1024 * 4);
scope(exit) Mallocator.it.deallocate(buffer);
which seems redundant and error prone.
Would it not be possible for allocate to automatically add itself
to the parent scope by default?
This way code like
auto buffer = Mallocator.it.allocate(1024 * 1024 * 4);
would automatically expand to
auto buffer = Mallocator.it.allocate(1024 * 1024 * 4);
scope(exit) Mallocator.it.deallocate(buffer);
If, say, we needed to "raise" the scope(exit) of allocate to act
on the parent of the parent scope then we could do something like
auto MyAllocate(size)
{
return scope(raise) { Mallocator.it.allocate(size); };
auto scope(parent) { print("Happy times"); };
}
auto buffer = MyAllocate(1024 * 1024 * 4);
So that allocate inside MyAllocate won't release the buffer on
the return of MyAllocate on use scope.
with scope hierarchy the above would translate into
auto buffer = MyAllocate(1024 * 1024 * 4);
Mallocator.it.deallocate(buffer);
print("Happy times");
This will allow wrapping automatic scope exits to behave properly.
Of course with such a feature one would also need to prevent
automatic scope assignment:
auto buffer = scope(none) MyAllocate(1024 * 1024 * 4);
would prevent any auto scope from My Allocate and subcalls from
being called.
This is just a rough suggestion that hopefully will lead to more
potent scope control and less error prone allocators. I believe
it should be somewhat easily implemented by having some type of
vtable like control for each function that is called after each
function to deal with the scope chaining.
Oct 31 2013
The 'it' property is only some 'singleton' approach.
You can write:
void foo() {
auto buffer = Mallocator.allocate(42);
/// ... many code
}
And at the end of the scope buffer is cleared because
Mallocator's destructor call deallocateAll (if I'm not wrong).
Oct 31 2013
On Thursday, 31 October 2013 at 22:03:18 UTC, Namespace wrote:
The 'it' property is only some 'singleton' approach.
You can write:
void foo() {
auto buffer = Mallocator.allocate(42);
/// ... many code
}
And at the end of the scope buffer is cleared because
Mallocator's destructor call deallocateAll (if I'm not wrong).
That doesn't seem right? deallocateAll would deallocate all
allocated objects? Even outside of foo's scope? Also, how would
Mallocator.allocate know what to deallocate unless it kept a
history? Why would the example code explicitly deallocate the
object at the end of the scope if it were unnecessary?
Oct 31 2013
On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:On Thursday, 31 October 2013 at 22:03:18 UTC, Namespace wrote:Sorry, I was tired. ^^ That is the correct code: void foo() { Mallocator m; auto buffer = m.allocate(42); } If m get out of scope, it deallocates all allocated memory.The 'it' property is only some 'singleton' approach. You can write: void foo() { auto buffer = Mallocator.allocate(42); /// ... many code } And at the end of the scope buffer is cleared because Mallocator's destructor call deallocateAll (if I'm not wrong).That doesn't seem right? deallocateAll would deallocate all allocated objects? Even outside of foo's scope? Also, how would Mallocator.allocate know what to deallocate unless it kept a history? Why would the example code explicitly deallocate the object at the end of the scope if it were unnecessary?
Nov 01 2013
"Stretto" <uiy12345 gmail.com> On Friday, 1 November 2013 at 08:59:36 UTC, Namespace wrote:On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:Ok, I can see that but what if we want a "global" allocator? Then we need an easy way to deallocate on scope exit. I see no way to do that implicitly without some like I've mentioned(the (de)allocator needs a way to add itself to the scope exit).On Thursday, 31 October 2013 at 22:03:18 UTC, Namespace wrote:Sorry, I was tired. ^^ That is the correct code: void foo() { Mallocator m; auto buffer = m.allocate(42); } If m get out of scope, it deallocates all allocated memory.The 'it' property is only some 'singleton' approach. You can write: void foo() { auto buffer = Mallocator.allocate(42); /// ... many code } And at the end of the scope buffer is cleared because Mallocator's destructor call deallocateAll (if I'm not wrong).That doesn't seem right? deallocateAll would deallocate all allocated objects? Even outside of foo's scope? Also, how would Mallocator.allocate know what to deallocate unless it kept a history? Why would the example code explicitly deallocate the object at the end of the scope if it were unnecessary?
Nov 01 2013