There are many situations where you need to express that something is “optional” - an object that might contain a value or not. You have several options to implement such case, but with C++17 there’s probably the most helpful way: std::optional. For today I’ve prepared one refactoring case where you can learn how to apply this new C++17 feature.

A few weeks ago I gave another talk at my local C++ user group. We discussed recent “goodies” from C++ and tools that can increase productivity. Intro   In my post for the “C++ summary at the end of 2017” I mentioned that we could see a considerable improvement in the area of tooling for the language.

The C++ Standard moves at a fast pace. Probably, not all developers caught up with C++11/14 yet and recently we got C++17. Now it’ time to prepare C++20! A few weeks ago The C++ Committee had an official ISO meeting in Jacksonville, FL (12-17 March 2018) where they worked hard on the new specification.

Let’s have a quick overview of another book related to Modern C++ and The Standard Library. This time I picked Rainer Grimm’s book the author of the modernescpp blog. Read more if you’d like to win C++ book bundle! :) The book   The C++ Standard Library What every professional C++ programmer should know about the C++ standard library

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? What happens before main()(*) ?

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? Intro   The main idea behind self-registering types is that each class need to register in the factory.

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.