I wrote more than 130 posts in my German blog about functional programming, embedded programming and multithreading programming with modern C++. My English blog will catch up in two months with my German one. Therefore, it’s the right time to rework my blogs. The German blog and the English blog in parallel.
I will talk about two nice properties of the move semantic in this post that is not so often mentioned. Containers of the standard template library (STL) can have non-copyable elements. The copy semantic is the fallback for the move semantic. Irritated? I hope so!
A lot was written about the advantages of move semantics to copy semantics. Instead of an expensive copy operation, you can use a cheap move operation. But what does that mean? In this post, I will compare the copy and move semantics performance for the Standard Template Library (STL) containers.
std::array combines the best of two worlds. On the one hand, std::array has the size and efficiency of a C array; on the other hand, std::array has the interface of a std::vector.
One of the significant advantages of a C++ string to a C string and of a std::vector to a C array is that both C++ containers automatically manage their memory. Of course, that holds for all further containers of the Standard Template Library. In this post, I will look closer at the automatic memory management […]
std::unique_ptr models the concept of exclusive ownership, std::shared_ptr the concept of shared ownership. If I stick to this picture then std::weak_ptr models the concept of temporary ownership because it borrows the resource from a std::shared_ptr. There is one dominant reason for having a std::weak_ptr in C++: breaking of cyclic references of std::shared_ptr‘s.
After I draw the big picture of a std::shared_ptr in the last post, I want to present two special aspects of this smart pointer in this post. First, I show with std::shared_from_this how to create a std::shared_ptr from an object; second, I’m interested in the question to the answer: Should a function take a std::shared_ptr […]
std::shared_ptr’s share the resource. The shared reference counter counts the number of owners. Copying a std::shared_ptr increases the reference count by one. Destroying a std::shared_ptr decreases the reference count by one. If the reference count becomes zero, the resource will automatically be released.
According to the RAII idiom, a std::unique_ptr manages automatically and exclusively the lifetime of its resource. std::unique_ptr should be your first choice because it does its work without memory or performance overhead.
C++11 offers four different smart pointers. I will have a closer look in this post regarding memory and performance overhead on two of them. My first candidate, std::unique_ptr takes care of the lifetime of one resource exclusively; std::shared_ptr shares the ownership of a resource with another std::shared_ptr. I will state the result of my tests […]