Feature Request: steal backing array in flat map/set

[yonik]

One feature that would greatly decrease peak memory usage in my use-case is to have the ability to "steal" the backing array from the flat-maps (after compacting them into a "normal" array first of course.)

The use-case is currently implemented as follows:

1. add / update many objects in a flat_hash_set
2. allocate a new array, iterate over the flat_hash_set, adding all to the array
3. delete the flat_hash_set
4. sort the array of objects

Perhaps something along the lines of:

// Removes and returns an array of all entries in the set.  Optimized implementations may re-use an internal array, thus
// lowering memory usage.  Only the first size() entries are defined.  It is the callers responsibility to delete the returned array.
value_type* remove_all_entries()

Oh, and thank you for the inspired lazy_emplace()! It's still more powerful than other map/set implementations of try_emplace since key creation can be deferred or customized as well.

[greg7mdp]

Thanks for the kind words!

have the ability to "steal" the backing array from the flat-maps (after compacting them into a "normal" array first of course.)

Should not be too difficult to do. Let me look into it.

[greg7mdp]

Hum, there is the issue of the allocator used for allocating the array inside the flat_hash_set. If you steal the buffer, then you also need to use the same allocator to free the memory buffer eventually. I wish there was a way to construct a std::vector from a pointer, size, capacity and optional allocator. I don't want to implement my own gtl::vector.

But it would be nice, we could have a gtl::vector which could be constructed using:

vector::vector(gtl::flat_hash_set&&);

and that move constructor would steal the underlying array (after compaction).

[yonik]

Hum, there is the issue of the allocator used for allocating the array inside the flat_hash_set

Yeah, I figured it could be a super-low-level expert method where the caller may even be in charge of calling individual destructors (making it possible is better than nothing at all IMO). Either that, or as you suggest, your own little vector-like class.

[greg7mdp]

OK, I did the first part, added gtl::vector.