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.

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.

How do you see the new C++ standard? Is it ok? Great? Meh? Last week, after a few years of break, I presented my new talk that addressed the above question! It happened at the Cracow C++ Local Group. Have a look what’s inside this talk. Intro   Listing all of the features from the new standard might sound simple at first glance.