Saying that C++ has simple rules for variables initialization is probably quite risky :) For example, you can read Initialization in C++ is Bonkers : r/cpp to see a vibrant discussion about this topic. But let’s try with just a small part of variables: static variables. How are they initialized?

This post is motivated by one important comment from my last article about factories and self-registering types: (me) So the compiler won’t optimize such variable. Yet, unfortunately, the linker will happily ignore it if linking from a static library. So… what’s the problem with the linker?

Writing a factory method might be simple: unique_ptr<IType> create(name) { if (name == "Abc") return make_unique<AbcType>(); if (name == "Xyz") return make_unique<XyzType>(); if (...) return ... return nullptr; } Just one switch/if and then after a match you return a proper type. But what if we don’t know all the types and names upfront?

Inside const methods all member pointers become constant pointers. However sometimes it would be more practical to have constant pointers to constant objects. So how can we propagate such constness? The problem Let’s discuss a simple class that keeps a pointer to another class. This member field might be an observing (raw) pointer, or some smart pointer.

Let’s see pimpl and its alternatives in a real application! I’ve implemented a small utility app - for file compression - where we can experiment with various designs. Is it better to use pimpl or maybe abstract interfaces? Read on to discover. Intro In my previous post I covered the pimpl pattern.

Have you ever used the pimpl idiom in your code? No matter what’s your answer read on :) In this article I’d like to gather all the essential information regarding this dependency breaking technique. We’ll discuss the implementation (const issue, back pointer, fast impl), pros and cons, alternatives and also show examples where is it used.

In Poland, it’s only a few hours until the end of the year, so it’s an excellent chance to make a summary of things that happened to C++! As you might guess the whole year was dominated by the finalization and publication of C++17. Yet, there are some other “big” things that happened.

When I was working on the Smart Pointer Reference Card I run into a quite interesting issue. It appears that in some cases memory allocated for the object controlled by smart_ptr might not be released until all weak pointers are also ‘dead’. Such case was surprising to me because I thought that the moment the last share_ptr goes down, the memory is released.

Modern C++ stresses the use of RAII objects to manage resources. One of the easiest ways is just to start using unique_ptr across your code. Let’s see how we can leverage this smart pointer type. I’ve come up with 5 (or more?) reasons where unique_ptr shines. Intro One of my favourite features of modern C++ is smart pointers.

For my article series about C++17 features, I’ve made a separate entry about new attributes. At first sight, I thought that [[nodiscard]] is just another simple and a rarely used thing. But later I thought… hmmm… maybe it might be valuable? One reason is that [[nodiscard]] might be handy when enforcing code contracts.

The new C++ standard brings many useful additions to the Standard Library. So far we’ve discussed bigger features like the filesystem or parallel algorithms. Today, I want to focus on smaller, but also handy things. For example, there are utils for handling type safe unions, replacement of void*, string searchers and much more.

C++17 is on the way, and I’m glad to see more books that stay on the bleeding edge of C++ adaptation. Today I’d like to present a book that focuses on the Standard Library. Is this another great book? TL; DR: Yes :) But read more to see why :)