The careful handling of resources - may it be for example memory, files or sockets - is a key concern of programming in C++. This holds in particular true for the embedded programming that is often characterized by limited resources. Therefore, I will write a few posts about this challenging and versatile topic.

Plain Old Data (POD) obeys the C standard layout. Therefore, you directly can apply the fast C functions memcopy, memmove, memset, or memcmp.

The hash function maps a potential infinite number of keys on a finite number of buckets. What is the strategy of the C++ runtime and how can you tailor it to your needs, that is what this article is all about.

The reason for the constant access time (best cast) of the unordered associative containers are the hash functions. As ever, C++ offers a lot of ways to adjust the behaviour of the hash functions. On one hand, C++ has a lot of different hash functions; on the other hand, you can define your own hash function. You can even adjust the number of buckets.

Before I take a deeper look insight the interface of the hash tables - officially called unordered associative containers - I will at first compare the performance of the associative containers. The best candidates are std::unordered_map and the ordered pendant std::map because both are used most frequently.

We missed hash table in C++ for a long time. They promise to have constant access time. C++11 has hash tables in four variations. The official name is unordered associative containers. Unofficially, they are called dictionaries or just simple associative arrays. 

If you look carefully, you see, type-traits have a big optimization potential. The type-traits support in the first step to analyse the code at the compile time and in the second step, to optimize the code based on that analysis. How is that possible? Dependent on the type of a variable a faster variant of an algorithm will be chosen.