greg7mdp / gtl Goto Github PK

support bazel

Release - 1.1.3, but:

Commit: f80aefd

I think the std::erase_if overload might be undefined behavior.
Maybe it's better to use ADL (https://en.cppreference.com/w/cpp/language/adl) and declare erase_if in the gtl namespace?
Please check it.

Links:
https://en.cppreference.com/w/cpp/language/extending_std
https://stackoverflow.com/a/11599/590688

reinterpret_cast from float* to uint*_t* is UB (break strict aliasing).

Suggestions:

        uint32_t as_int;
        std::memcpy(&as_int, &val, sizeof(as_int));
        return (val == 0) ? static_cast<size_t>(0) :
                            static_cast<size_t>(as_int);

and

        uint64_t as_int;
        std::memcpy(&as_int, &val, sizeof(as_int));
        return (val == 0) ? static_cast<size_t>(0) :
                            fold_if_needed<sizeof(size_t)>()(as_int);

I am trying to remove duplicate and unused code in gtl.
Current state: https://github.com/phprus/gtl/tree/todo-1

I don't understand the need for declarations:

and

and

Maybe replace these definitions with using std::allocator, std::pair, std::equal_to, std::less directly?

Hi,

What's the use case for this library? Please add benchmarks against original implementation so that we can understand if this is faster.

Greg,
Do you have plans to add a multimap variant for your flat hash map?

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.

The header file phmap.hpp contains empty functions:

Some of these functions are not used anywhere.

Please tell me, are these functions needed or can they be removed?