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.

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).

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?

On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:
> 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?

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.

On Friday, 1 November 2013 at 08:59:36 UTC, Namespace wrote:
> On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:
>> 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?
>
> 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.

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).