C++11 offers four different smart pointers. On two of them, I will have a closer look in this post regarding memory and performance overhead. My first candidate std::unique_ptr takes exclusively care of the lifetime of one resource; std::shared_ptr shares the ownership of a resource with other std::shared_ptr's. I will state the result of my tests before I show you the raw numbers: There are only a few reasons in modern C++ justifying the memory management with new and delete.

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 potentially 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 the 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 variable a faster variant of an algorithm will be chosen.

constexpr functions are functions that can be executed at compile time. Sounds not so thrilling. But it is. Trust me. You can perform with constexpr functions a lot of calculations at compile time. Therefore, the result of the calculation is at runtime as a constant in ROM available. In addition, constexpr functions are implicitly inline.

If you declare a variable as constexpr the compiler will evaluate them at compile time. This holds not only true for built-in types but also for instantiations of user-defined types. There are a few serious restrictions for objects in order to evaluate them at compile time.