http://code.dlang.org/packages/aammm/~master

# aammm
Associative arrays with manual memory management

All enries and buckets would be dealocated and disposed by internal implementation's destructor.
The destructor is called by garbage collector (by default).

#### Example
```D
    //std.experimental.allocator is included into `aammm`
    import std.experimental.allocator.mallocator;
    import aammm;

    auto a = AA!(string, int, shared Mallocator)(Mallocator.instance);
    a["foo"] = 0;
    a.remove("foo"); //dealocates and disposes the entry
    assert(a == null); // should not crash
```
AAMMM is based on Andrei's allocators and Martin's associative arrays.

References:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
https://github.com/D-Programming-Language/druntime/pull/1282

Best Regards,
Ilya

On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:
> http://code.dlang.org/packages/aammm/~master
>
> # aammm
> Associative arrays with manual memory management
>
> [...]

Awesome, I was waiting for something like that. Thank you!

On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:

Nice! I'll try this!

>     auto a = AA!(string, int, shared Mallocator)

When does the third parameter need to be qualified as `shared`?

On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:
> http://code.dlang.org/packages/aammm/~master

It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA.

Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)?

I'm especially interested in using this for keys and values only with no indirections.

On 24-Aug-2015 15:01, Ilya Yaroshenko wrote:
> http://code.dlang.org/packages/aammm/~master
>
> # aammm
> Associative arrays with manual memory management
>
> All enries and buckets would be dealocated and disposed by internal
> implementation's destructor.
> The destructor is called by garbage collector (by default).
>

Rox!

> #### Example
> ```D
>      //std.experimental.allocator is included into `aammm`
>      import std.experimental.allocator.mallocator;
>      import aammm;
>
>      auto a = AA!(string, int, shared Mallocator)(Mallocator.instance);

Sure hope a factory to do IFTI is available? So that the following works:

auto a  = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced

>      a["foo"] = 0;
>      a.remove("foo"); //dealocates and disposes the entry
>      assert(a == null); // should not crash
> ```



-- 
Dmitry Olshansky

On Wednesday, 26 August 2015 at 06:41:41 UTC, Per Nordlöw wrote:
> On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:
>
> Nice! I'll try this!
>
>>     auto a = AA!(string, int, shared Mallocator)
>
> When does the third parameter need to be qualified as `shared`?

Only if you would use a shared allocator like Mallocator or GCAllocator.

I will add factory template like Dmitry suggested.

auto a  = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced

Ilya

On Wednesday, 26 August 2015 at 06:50:26 UTC, Per Nordlöw wrote:
> On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:
>> http://code.dlang.org/packages/aammm/~master
>
> It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA.
>
> Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)?


Yes, except constructor. To do not use constructor you can use `makeAA` and `disposeAA`.

> I'm especially interested in using this for keys and values only with no indirections.

On Wednesday, 26 August 2015 at 06:50:26 UTC, Per Nordlöw wrote:
> On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote:
>> http://code.dlang.org/packages/aammm/~master
>
> It would be nice to have a test example for other allocators. I'm especially interested in how much speed we can gain with using a non-shared BlockAllocator in combination with aammm.AA.
>
> Can the whole AA be made `@safe pure nothrow` if the allocator is stored inside the AA itself (non-shared)?

EDIT: Plus I think to RefCountingAA.

> I'm especially interested in using this for keys and values only with no indirections.

On Wednesday, 26 August 2015 at 06:52:01 UTC, Dmitry Olshansky wrote:
>>
>>      auto a = AA!(string, int, shared Mallocator)(Mallocator.instance);
>
> Sure hope a factory to do IFTI is available? So that the following works:
>
> auto a  = aa!(string, int)(Mallocator.instance); // 3rd CT param is deduced
>

Just added to master branch) Thanks!

On Wednesday, 26 August 2015 at 10:48:11 UTC, Ilya Yaroshenko >> auto a  = aa!(string, int)(Mallocator.instance); // 3rd CT

highlights

It would be nice to also see an example at
https://github.com/arexeu/aammm

that shows AA-usage in conjunction with some other allocator such as FreeList and add a note about the performance improvement this gives.

In that case, would it be possible to have factory functions for AA that automatically derives allocator parameters from key and value type for specific allocators?

What do you say?