Detailed Description

template<typename K, typename T, typename H = strhash<K>, typename E = streql<K>>
class simstr::hashStrMap< K, T, H, E >

Container for more efficient searching by string keys.

Used to store and lookup keys of any string type. Like unordered_map, but a little better. Stores simple_str as keys along with the calculated hash and an empty space for sstring. After insertion, creates an sstring in this empty space so that simple_str has something to refer to. Allows you to use any simstr string objects for insertion and search, creating an object from them sstring only for real insertion. Since C++20, unordered_map has the ability to perform heterogeneous search by key with type, different from the type of the key being stored, but this requires some dancing with hash types and comparisons. Search with insertion (try_emplace) by a type other than the key type appears in the standard only with C++26. There is a hashing and comparison implementation for the options:

case sensitive
case insensitive, ASCII only
case insensitive, simplified Unicode (up to 0xFFFF). Hashing is performed by the FNV-1A algorithm. Automatic conversion of simstr string objects to the type of the stored key (i.e. with a calculated hash), and also saving sstring in the key when inserting - performed for the try_emplace, emplace, at, methods find, operator[], erase. When using other search methods, you need to provide the correct calculated hash in the StoreType key. Do not use insertion methods other than those listed; they are not will save sstring in the key.

The main thing I would like to focus on is the very purpose of strHashMap, for which it was originally invented. The goal was not to somehow beat unordered_map in terms of performance/memory (otherwise why make strHashMap on unordered_map database?) The main problem that was solved is that we have several options for string objects, and I would like to be able to use any type of string object to insert and search for keys. We have simple_str, simple_str_nt, sstring, and lstring<N> in general for every N is a new object type. In std everything was simple - there was only string, and accordingly, we used unordered_map<string, Something there>. And by the way, in std we encountered the same problem: the keys are const char*, and with C++17 and string_view (this is like our simple_str), searching in unordered_map<string, Type> is not very good, you have to convert the key to string every time, although you can do without this. Therefore, starting from C++20, the possibility of heterogeneous search was added to unordered_map - on https://en.cppreference.com/w/cpp/container/unordered_map/find these are syntaxes (3) and (4). True, this requires ritual dances with a tambourine - a special type is required for hashing (which, of course, in the standard is no longer included and you need to implement it yourself), which can hash different types of keys, and contains typename is_transparent. In fact, there is an example of it on the same page. This solved part of the problem - search, but did not solve the insertion problem - for inserting into unordered_map<string, Type> still only requires string. And only in the future C++26 we expect the possibility of heterogeneous insertion in the form try_emplace (https://en.cppreference.com/w/cpp/container/unordered_map/try_emplace) in syntax (6), which will allow you to accept keys of other types and convert them to the desired type only if the insertion is actually carried out. In my string library, I encountered this problem even before C++17, and so I’m not so cool as to influence the standard, I simply created my own class - a descendant of unordered_map, with wrappers around the insertion/search methods. Well, I also added two more hashing/comparison options: case-insensitive ASCII, case-insensitive simple unicode. Thus, we have a class that extends the standard unordered_map with the ability to work with string keys of different types, allowing you to avoid unnecessary unnecessary key conversions when searching and inserting. The fact that performance may improve is not the goal, but a side effect - pleasant, if there is one, but not fatal if it is not there.

The documentation for this class was generated from the following file:

sstring.h