trouble with unordered_map and stateful allocators about memory HOT 3 CLOSED

I need to look into that.

For me it also seems that there is no hashing for strings with custom allocators.

from memory.

Okay, I think I found the issue.

The operator[] of map first needs to create a default constructed key-value pair. However, my::string uses a stateful allocator and stateful allocators aren't default constructible, so it fails. You just can't use operator[], just like you can't use it if you have a "normal" non-default constructible type.

However, the error message could be nicer.

from memory.

First of all, thanks for looking into this! Following posting the issue yesterday, I started looking into allocators in a bit more depth. I found this talk from CPPCon2014 on the subject:

Making Allocators Work - Part 1
Making Allocators Work - Part 2

And there is a bit about building container of non trivial objects and how one should go about and do it. He mentions std::scoped_allocator_adaptor<...> which are precisely there to inject the allocator of the container in the constructor of the contained item by highjacking the construct method of the allocator. His example is a vector<string> allocated using a shared memory allocator which is should both be used to allocate the vector memory as well as the string memory.

So this morning, I thought I'd just use that and it should work. So I rewrote the type system as follows:

    template<typename T>
    using allocator = std::scoped_allocator_adaptor<foonathan::memory::std_allocator<T, my::raw_stat_mallocator>>;

    template<typename C>
    using basic_string = std::basic_string<C, std::char_traits<C>, allocator<C>>;

    using string = std::basic_string<char>;

    template<typename K, typename V>
    using hash_map = std::unordered_map<K, V, std::hash<K>, std::equal_to<K>, allocator<std::pair<const K, V>>>;

But that does not compile either (something about alloc_referencenot being able to access a private base class or something). However, trying some more random stuff, I simply removed the scoped_allocator_adaptor from the above type system. And hey, it works. I'm still puzzled, because it looks like I'm just redefining what's done in Container.hpp, but obviously there is subtle difference that eludes me at the moment. I'll continue digging.

Anywho, here's what I've got so far:

    // ... same as above

    template<typename T>
    using allocator = foonathan::memory::std_allocator<T, my::raw_stat_mallocator>;

    template<typename C>
    using basic_string = std::basic_string<C, std::char_traits<C>, allocator<C>>;

    using string = std::basic_string<char>;

    template<typename K, typename V>
    using hash_map = std::unordered_map<K, V, std::hash<K>, std::equal_to<K>, allocator<std::pair<const K, V>>>;
}


int main()
{
    auto ral = my::raw_stat_mallocator();
    auto m1 = my::hash_map<int, my::string>(ral);
    auto m2 = my::hash_map<my::string, int>(ral);

    // both of these work fine and (added bonus) I don't have 
    // to explicitly instantiate the strings with ral :-)
    m1[2] = "hello"; 
    m2["hello"] = 2;
    return EXIT_SUCCESS;
}

which produced the following output, which seems reasonable to me:

[ 0x7fff5c438430 ] Allocating 48 bytes (0 total, 0 current)
[ 0x7fff5c438430 ] Allocating 16 bytes (48 total, 48 current)
[ 0x7fff5c438430 ] Allocating 48 bytes (64 total, 64 current)
[ 0x7fff5c438430 ] Allocating 16 bytes (112 total, 112 current)
[ 0x7fff5c438430 ] Deallocating 48 bytes (128 total, 128 current)
[ 0x7fff5c438430 ] Deallocating 16 bytes (128 total, 80 current)
[ 0x7fff5c438430 ] Deallocating 48 bytes (128 total, 64 current)
[ 0x7fff5c438430 ] Deallocating 16 bytes (128 total, 16 current)

from memory.