DEV Community: Bartlomiej Filipek

Modern C++: Safety and Expressiveness with override and final

Bartlomiej Filipek — Wed, 14 Apr 2021 20:33:32 +0000

While C++11 is with us for a decade now, it's good to go back and recall some of its best features. Today I'd like to consider override and final keywords which add a crucial safety when you build class hierarchies with lots of virtual member functions.

See how to prevent common bugs, and how to leverage tools to make your code safer.

Initially published at CppStories

An Unexpected Code Path Errors

Can you spot an error in the following code?

There's a base class - BasePacket and a single derived class - NetworkPacket:

class BasePacket {
public:
    virtual ~BasePacket() = default;

    virtual bool Generate() = 0;
    virtual bool Verify(std::string_view ) { return true; }
};

class NetworkPacket : public BasePacket {
public:
    NetworkPacket() = default;

    bool Generate() { return true; }

    bool Verify(std::string_view config) const {
        std::cout << "verifying against: " << config;
        return true;
    }

private:
    std::any data_;
};

And then we have a simple use case. We'd like to call the Verify function using a pointer to the base class:

int main() {
    std::unique_ptr<BasePacket> pPacket = std::make_unique<NetworkPacket>();
    pPacket->Verify("test cfg: length: 123: https: false");
}

Do you know what's the output here? Give it a try and think a minute.

Here's the output:

Yep, it's an empty line. There's no sensible output as our derived Verify function from NetworkPacket wasn't called at all!

The reason?

As you can see, we have two different function declaration:

bool NetworkPacket::Verify(std::string_view config) const;

And

virtual bool BasePacket::Verify(std::string_view config);

Since they don't match the compiler can call only the base class's function (as we call it through a pointer to the base class). The function from NetworkPacket is not available for the overload resolution at this stage.

We can imagine that one developer created the base class, another developer wrote the NetworkPacket and wanted to narrow the contract of this particular function and make it const.

In our example we have a mismatch on const, but it can happen also with parameter types:

bool NetworkPacket::Verify(std::string_view config, int arg) const;
// vs
virtual bool BasePacket::Verify(std::string_view config, double arg) const;

See the code @Compiler Explorer

A Complex Case With `#define`

There's even more fun! See this example:

In one article @PVS-Studio blog there's an interesting case where functions match in 32-bit compilation mode, but when you change to 64-bit, then it fails. Have a look at this synthesised example:

//#define WIN64 // uncomment later...

typedef uint32_t DWORD;

#ifdef WIN64
typedef uint64_t DWORD_PTR;
#else
typedef DWORD DWORD_PTR;
#endif

struct Base {
    virtual int execute(DWORD_PTR dwData) { return 1; };
};

struct Derived : public Base {
    int execute(DWORD dwData) { return 2; }; 
};

int run(Base& b) { return b.execute(0); }

int main() {
    Derived d;
    return run(d);
}

As you can see above, there's a mismatch in the function declarations. This example is based on a real use case in some WinApi code! The code works nicely in 32 bits when DWORD and DWORD_PTR matches and both mean uint32_t. However, when you define WIN64 then things came apart and fail.

See the example @Compiler Explorer. Have a look at the program's output, in one case it's 1, and in the second case it's 2.

See more in Lesson 12. Pattern 4. Virtual functions @PVS-Studio Blog.

Risks - Sum Up

What do we risk when the virtual functions don't match?

Wrong code path might be executed. This case is particularly scary when you have large hierarchies with complex code; some function may call other base functions, so deducing what's wrong might not be an easy debugging task.
Hard to read code. Sometimes it's not clear if a function overrides a virtual one from the base class or not. Having a separate keyword makes it visible and explicit.

The Solution - Apply `override`

Before C++11, it was quite common to have those kinds of errors and misuses. Such bugs were also quite hard to spot early on. Fortunately, following the path of other programming languages like Java or C# Modern C++ gave us a handy keyword override.

In C++ we should make a habit of marking every function which overrides with the override contextual keyword. Then the compiler knows the expected results and can report an error. In our case when I add override to the NetworkPacket implementation:

bool Verify(std::string_view config) const override {
    std::cout << "verifying against: " << config;
    return true;
}

I'll immediately get a compiler error:

 error: 'bool NetworkPacket::Verify(std::string_view) const' marked 'override', but does not override
   21 |  bool Verify(std::string_view config) const override {
      |       ^~~~~~

This is much better than getting the wrong path execution after a few days :)

Same happens for our WIN64 example. When you apply override you'll get a nice warning:

error: 'int Derived::execute(DWORD)' marked 'override', but does not override

See the improved code @Compiler Explorer.

Additionally, there's also a "reverse" situation:

What if our base class designer forgot to make a function virtual? Then we can expect a similar error.

In both situations, we have to go back and compare the declarations and see what's wrong.

The override keyword also reduces the need to write virtual in every possible place.

struct Base {
    virtual void execute() = 0;
};

struct Derived : public Base {
    virtual void execute() { }; // virtual not needed
};

Before C++11, it was common to put virtual to mark that this function is overriding, but only the top-most functions in the base class need such a declaration. It's much better to use override:

struct AnotherDerived : public Base {
    void execute() override { }; // better!
};

Guidelines

Let's also have a look at Core Guidelines: We have a separate topic on override:

C.128: Virtual functions should specify exactly one of virtual, override, or final - link

We can read in the guideline with override we aim to address the following issues:

implicit virtual - you wanted (or didn't wish to) a function to be virtual, but due to some subtle differences with the declaration it isn't (or is).
implicit override - you wanted (or didn't want) a function to be an override, but it appears to be the opposite way.

We can also have a look at Google C++ Style Guide where we can find:

Explicitly annotate overrides of virtual functions or virtual destructors with exactly one of an override or (less frequently) final specifier. Do not use virtual when declaring an override....

Adding `final`

If you want to block the possibility to override then C++11 also brings another keyword final. See the example below:

struct Base {
    virtual void doStuff() final;
};

struct Derived : public Base {
    void doStuff(); 
};

And Clang reports:

<source>:6:10: error: virtual function 'virtual void Derived::doStuff()' overriding final function
    6 |     void doStuff();
      |          ^~~~~~~

See here @CompilerExplorer

It's also not a problem to mix override with final (although it's harder to read and probably uncommon):

struct Base {
    virtual void doStuff();
};

struct Derived : public Base {
    void doStuff() override final; 
};

struct ExDerived : public Derived {
    void doStuff() override; 
};

This time, we allow to override in one base class, but then we block this possibility later in the hierarchy.

It also appears that the final keyword can be used to ensure your functions are properly marked with override.

Have a look at this response by Howard Hinnant:

c++ - Is there any sense in marking a base class function as both virtual and final? - Stack Overflow

I marked the virtual function in the base class with final, and the compiler quickly showed me where every single override was declared. It was then very easy to decorate the overrides how I wanted, and remove the final from the virtual in the base class.

Another interesting use case is with giving the compiler more ways to devirtualise function calls.

See a separate blog post on that in the MSVC Team blog: The Performance Benefits of Final Classes | C++ Team Blog.

Tools

After the standardisation of C++11, many useful tools started to appear and catch up with the Standard. One of the best and free tools is clang-tidy which offers help with code modernisation.

Usually when you forget to apply override the compiler can do nothing about it and won't report any errors.

We can enable clang-tidy in Compiler Explorer and if we pass the following command:

--checks='modernize-use-override'

We will get the following report:

<source>:19:7: warning: annotate this function with 'override' 
               or (rarely) 'final' [modernize-use-override]
        bool Generate() { return true; }
             ^
            override
<source>:21:7: warning: annotate this function with 'override' 
               or (rarely) 'final' [modernize-use-override]
        bool Verify(std::string_view config) {
             ^
            override

Here's the configured Compiler Explorer output: https://godbolt.org/z/jafxTn and the screenshot:

And here's the list of all checks available in Clang Tidy. You can experiment and find some other suggestions from the tool.

If you want to read more you can also have a look at my separate guest post on Clang-Tidy: A Brief Introduction To Clang-Tidy And Its Role in Visual Assist – Tomato Soup.

Summary

The override keyword is very simple to use and makes your code more expressive and more straightforward to read. There's no downside of using it and, as you could see in one example, without it we sometimes risk some unwanted code path to be executed!

For completeness, you can also leverage final to have more control over the virtual functions and permissions which classes can or shouldn't override functions.

We also looked at a popular and easy-to-use tool clang-tidy that can help us automate the process of modernising code bases.

Your Turn

What's your experience with override? Do you use it? Is that your habit?
Have you tried final? I'm interested in some good use cases for this feature.

More from the Author

Bartek is author of two books - "C++17 In Detail" and "C++ Lambda Story" - both available @Leanpub - Learn Modern C++ in a practical way.

C++20 Cheatsheet (with examples)

Bartlomiej Filipek — Tue, 28 Jan 2020 08:13:03 +0000

While the C++20 Standard is still being finalised and polished we know all of its core features. At first, the new specification of the language might sound complex and overwhelming. That's why, if you want to have an overview of the core elements and get the bigger picture, you can have a look at my new reference card.

Want your own copy to print?

If you like, I prepared PDF I packed both language and the Standard Library features. Each one has a little description and an example if possible.

Here's what the text covers:

Concepts
Modules
Coroutines
operator <=>
Designated Initializers
Range-based for with initializer
char8_t
New attributes
Structured Bindings Updates
Class non type template parameters
explicit(bool)
constexpr Updates
consteval
constinit
std::format
Ranges
Chrono Library Updates
Multithreading and Synchronisation
std::span
and many others

All of the existing subscribers of my mailing list have already got the new document, so If you want to download it just subscribe here:

Download a free copy of C++20 Ref Card!

Please notice that along with the new ref card you'll also get C++17 language reference card that I initially published three years ago. With this "package" you'll quickly learn about all of the latest parts that Modern C++ acquired over the last few years.

Let's now go through some of the core parts of C++20

Language Features

Concepts

Constrains on the template parameters and meaningful compiler messages in a case on an error. Can also reduce the compilation time.

template <class T>
concept SignedIntegral = std::is_integral_v<T> &&
                         std::is_signed_v<T>;
template <SignedIntegral T> // no SFINAE here!
void signedIntsOnly(T val) { }

Also with terse syntax:

void floatsOnly(std::floating_point auto fp) { }

(constrained auto)

Modules

The replacement of the header files! With modules, you can divide your program into logical parts.

import helloworld; // contains the hello() function
int main() {
   hello(); // imported from the “helloworld” module!
}

Designated Initializers

Explicit member names in the initializer expression:

struct S { int a; int b; int c; };
S test {.a = 1, .b = 10, .c = 2};

Range-based for with initializer

Create another variable in the scope of the for loop:

for (int i = 0; const auto& x : get_collection()) {   
    doSomething(x, i);   
    ++i; 
}

Attributes

[[likely]] - guides the compiler about more likely code path
[[unlikely]] - guides the compiler about uncommon code path
[[no_unique_address]] - useful for optimisations, like EBO
[[nodiscard]] for constructors – allows us to declare the constructor with the attribute. Useful for ctors with side effects, or RAII.
[[nodiscard("with message")]] – provide extra info
[[nodiscard]] is also applied in many places in the Standard Library

consteval

A new keyword that specifies an immediate function – functions that produce constant values, at compile time only. In contrast to constexpr function, they cannot be called at runtime.

consteval int add(int a, int b) { return a+b; }
constexpr int r = add(100, 300);

Others

plus many more like coroutines, constinit, CTAD updates and more!

Library Features

`std::format`

Python-like formatting library in the Standard Library!

auto s = std::format("{:-^5}, {:-<5}", 7, 9);

s has a value of „--7--, 9----” centred, and then left aligned
Also supports the Chrono library and can print dates.

Ranges

A radical change how we work with collections! Rather than use two iterators, we can work with a sequence represented by a single object.

std::vector v { 2, 8, 4, 1, 9, 3, 7, 5, 4 };
std::ranges::sort(v);
for (auto& i: v | ranges:view::reverse) cout << i;

With Ranges we also get new algorithms, views and adapters.

`std::span`

A non-owning contiguous sequence of elements. Unlike string_view, span is mutable and can change the elements that it points to.

vector<int> vec = {1, 2, 3, 4};
span<int> spanVec (vec);
for(auto && v : spanVec) v *= v;

Others

joining thread, semaphores, latches and barriers, Chrono library updates with calendar and timezones, source_location, erase/erase_if container functions, and many more!

Summary

I hope with this concise reference card it will be easier to understand the scope of the new Standard.

Do you like the new features of C++20? What's your favourite part? Let us know in comments.

Once again, if you want to have a nice-looking pdf, just grab it from here:

Download a free copy of C++20 Ref Card!

2 Lines Of Code and 3 C++17 Features - The overload Pattern

Bartlomiej Filipek — Fri, 26 Jul 2019 06:05:30 +0000

While I was doing research for my book and blog posts about C++17 several times I stumbled upon this pattern for visitation of std::variant:

template<class... Ts> struct overload : Ts... { using Ts::operator()...; };
template<class... Ts> overload(Ts...) -> overload<Ts...>;

std::variant<int, float> intFloat { 0.0f };
std::visit(overload(
        [](const int& i) { ... },
        [](const float& f) { ... },
    ),
    intFloat;
);

With the above pattern, you can provide separate lambdas “in-place” for visitation.

It’s just two lines of compact C++ code, but it packs a few interesting concepts.

Let’s see how this thing works and go through the three new C++17 features that enable this one by one.

Originally posted at bfilipek.com

Intro

The code mentioned above forms a pattern called overload (or sometimes overloaded), and it’s mostly useful for std::variant visitation.

With such helper code you can write:

std::variant<int, float, std::string> intFloatString { "Hello" };
std::visit(overload
  {
    [](const int& i) { std::cout << "int: " << i; },
    [](const float& f) { std::cout << "float: " << f; },
    [](const std::string& s) { std::cout << "string: " << s; }
  },
  intFloatString
);

The output:

string: Hello

Little reminder: std::variant is a helper vocabulary type, a discriminated union. As a so-called sum-type it can hold non-related types at runtime and can switch between them by reassignment std::visit allows you to invoke an operation on the currently active type from the given variant. Read more in my blog post Everything You Need to Know About std::variant from C++17.

Without the overload you’d have to write a separate class or struct with three overloads for the () operator:

struct PrintVisitor
{
    void operator()(int& i) const {
        std::cout << "int: " << i;
    }

    void operator()(float& f) const {
        std::cout << "float: " << f;
    }

    void operator()(std::string& s) const {
    std::cout << "string: " << s;
    }
};

std::variant<int, float, std::string> intFloatString { "Hello" };

std::visit(PrintVisitor(), intFloatString);

As you might already know the compiler conceptually expands lambda expression into a uniquely-named type that has operator().

What we do in the overload pattern is that we create an object that inherits from several lambdas and then exposes their operator() for std::visit. That way you write overloads “in place”.

What are the C++17 features that compose the pattern?

Pack expansions in using declarations - short and compact syntax with variadic templates.
Custom template argument deduction rules - that allows converting a list of lambdas into a list of base classes for the overloaded class.
Extension to aggregate Initialization - the overload pattern uses a constructor to initialise, but we don’t have to specify it in the class. Before C++17 it wasn’t possible.

New Features

Let’s explore section by section the new elements that compose the overload pattern. That way we can learn a few interesting things about the language.

Using Declarations

There are three features here, but it’s hard to tell which one is the simplest to explain.

But let’s start with using. Why do we need it at all?

To understand that let’s write a simple type that derives from two base classes:

#include <iostream>

struct BaseInt
{
    void Func(int) { std::cout << "BaseInt...\n"; }
};

struct BaseDouble
{
    void Func(double) { std::cout << "BaseDouble...\n"; }
};

struct Derived : public BaseInt, BaseDouble
{
    //using BaseInt::Func;
    //using BaseDouble::Func;
};

int main()
{
    Derived d;
    d.Func(10.0);
}

We have two bases classes that implement Func. We want to call that method from the derived object.

Will the code compile?

When doing the overload resolution set, C++ states that the Best Viable Function must be in the same scope.

So GCC reports the following error:

error: request for member 'Func' is ambiguous

See a demo here @Coliru

That’s why we have to bring the functions into the scope of the derived class.

We have solved one part, and it’s not a feature of C++17. But how about the variadic syntax?

The issue here was that before C++17 using... was not supported.

In the paper Pack expansions in using-declarations P0195R2 - there’s a motivating example that shows how much extra code was needed to mitigate that limitation:

template <typename T, typename... Ts>
struct Overloader : T, Overloader<Ts...> {
    using T::operator();
    using Overloader<Ts...>::operator();
    // […]
};

template <typename T> struct Overloader<T> : T {
    using T::operator();
};

In the example above, in C++14 we had to create a recursive template definition to be able to use using. But now we can write:

template <typename... Ts>
struct Overloader : Ts... {
    using Ts::operator()...;
    // […]
};

Much simpler now!

Ok, but how about the rest of the code?

Custom Template Argument Deduction Rules

We derive from lambdas, and then we expose their operator() as we saw in the previous section. But how can we create objects of this overload type?

As you know the type of a lambda is not know, so without the template deduction for classes, it’s hard to get it. What would you state in its declaration?

overload<LambdaType1, LambdaType2> myOverload { ... } // ???
// what is LambdaType1 and LambdaType2 ??

The only way that could work would be some make function (as template deduction works for function templates since like always):

template <typename... T>
constexpr auto make_overloader(T&&... t) {
   return Overloader<T...>{std::forward<T>(t)...};
}

With template deduction rules that were added in C++17, we can simplify the creation of common template types.

For example:

std::pair strDouble { std::string{"Hello"}, 10.0 };
// strDouble is std::pair<std::string, double>

There’s also an option to define custom deduction guides. The Standard library uses a lot of them, for example for std::array:

template <class T, class... U>  
array(T, U...) -> array<T, 1 + sizeof...(U)>;

and the above rule allows us to write:

array test{1, 2, 3, 4, 5};
// test is std::array<int, 5>

For the overload patter we can write:

template<class... Ts> overload(Ts...) -> overload<Ts...>;

Now, we can type

overload myOverload { [](int) { }, [](double) { } };

And the template arguments for overload will be correctly deduced.

Let’s now go to the last missing part of the puzzle - aggregate Initialization.

Extension to Aggregate Initialisation

This functionality is relatively straightforward: we can now initialise a type that derives from other types.

As a reminder: from dcl.init.aggr:

An aggregate is an array or a class with

no user-provided, explicit, or inherited constructors ([class.ctor])

no private or protected non-static data members (Clause [class.access]),

no virtual functions, and

no virtual, private, or protected base classes ([class.mi]).

For example (sample from the spec draft):

struct base1 { int b1, b2 = 42; };
struct base2 {
  base2() {
    b3 = 42;
  }
  int b3;
};

struct derived : base1, base2 {
  int d;
};

derived d1{ {1, 2}, {}, 4};
derived d2{ { }, {}, 4};

initializes d1.b1 with 1, d1.b2 with 2, d1.b3 with 42, d1.d with 4, and d2.b1 with 0, d2.b2 with 42, d2.b3 with 42, d2.d with 4.

In our case, it has a more significant impact.

For our overload class, we could implement the following constructor.

struct overload : Fs... 
{
  template <class ...Ts>
  overload(Ts&& ...ts) : Fs{std::forward<Ts>(ts)}...
  {} 

  // ...
}

But here we have a lot of code to write, and probably it doesn’t cover all of the cases…

With aggregate initialisation, we “directly” call the constructor of lambda from the base class list, so there’s no need to write it and forward arguments to it explicitly.

Playground

Play with the code @Coliru

Summary

The overload pattern is a fascinating thing. It demonstrates several C++ techniques, gathers them together and allows us to write shorter syntax.

In C++14 you could derive from lambdas and build similar helper types, but only with C++17 you can significantly reduce boilerplate code and limit potential errors.

You can read more in the proposal for overload P0051 (not sure if that goes in C++20, but it’s worth to see discussions and concepts behind it).

The pattern presented in this blog post supports only lambdas and there’s no option to handle regular function pointers. In the paper, you can see a much more advanced implementation that tries to handle all cases.

Your Turn

Have you used std::variant and visitation mechanism?
Have you used overload pattern?

References

More from the Author

Bartek recently published a book - "C++17 In Detail" available @Leanpub - rather than reading the papers and C++ specification drafts, you can use this book to learn the new Standard in an efficient and practical way.

11 Visual C++ Debugging Tips That Will Save Your Time

Bartlomiej Filipek — Tue, 23 Jul 2019 19:31:10 +0000

Programming is not only typing the code and happily see how smoothly it runs. Often it doesn’t run in a way we imagine! Thus, it’s crucial to debug apps effectively. And, it appears that the debugging is an art on its own! Here’s my list of tips that hopefully could help in debugging native code.

Originally published at bfilipek.com

Helpers

Everyone should know how to start the debugger, set a breakpoint, continue code execution, step in, step out (using keyboard!). Here are some smaller tips that extend those common actions.

1. Add LinePos to your debug output

No matter how proficient you are, I think, you will still use one of the basic methods: trace some values using printf, TRACE, outputDebugString, etc… and scan the output while debugging. In Visual Studio there’s a nice trick that allows you to quickly move from the debug output window to the particular line of code.

Just use the following syntax for the output format:

"%s(%d): %s", file, line, message

But remember to use file and line from the actual position in the source file, not in some logging function. Thus you should probably have a macro like that:

#define MY_TRACE(msg, ...) MyTrace(__LINE__, __FILE__, msg, __VA_ARGS__)

// usage:
MY_TRACE("hello world %d", 5);

Note that __LINE__ and __FILE__ are common, ANSI-Compliant, preprocessor defines that are available to your compiler. See Predefined Macros, MSDN

One more thing: remember to use OutputDebugString so that the message goes into Output Window, not console…

When a particular message goes to the VS output window, you can now double click on the message and VS will move you to that file and line. Same happens for viewing warnings or errors during compilation. I’ve lost a lot of time when I saw a message but I couldn’t know the exact place in the code. In that case I needed to search for the string… that is slow and not effective. With double-click it’s a matter of milisec to be in the proper destination.

BTW: If you use other IDE (other than Visual Studio) do you know if they support similar double-click feature? Let me know, because I am curious.

Here is some simple sample you can play: github.com/fenbf/DebuggingTipsSamples

Update: as jgalowicz mentioned in the comments. If you really like to have only short filenames in the output you can play with his __SHORT_FILE__ technique: see here on his blog..

Still, by default Visual Studio uses /FC compiler option off by default, so you usually have short filenames (probably relative to your solution dir only)

2. Simple static variable to control the feature

// change while debugging if needed
static bool bEnableMyNewFeature = true;

Edit And Continue in Visual studio is really powerful feature, but here’s a simplified , ‘manual ’ version. Probably not that beautiful, but works. Just make a static variable that can be used to control a feature. Could be just a boolean flag, or an integer. Then, while debugging you can actually change that value. Without the need to restart the program or recompile you can play with your feature.

How to change the value during debugging? Go to the watch window or just hover on top of the variable. You should see an edit box where the value can be changed.

Please remember to disable/remove that ugly variable in the final builds and commits!

3. Conditional breakpoints

I hope you use conditional breakpoints already, but let me just quickly show their basic uses. As name suggests you can set a condition, relatively simple one, upon which a debugger will stop.

One hint: write a custom breakpoint if you need more advanced test.

Here the list of expressions you can use in conditions: msdn: Expressions in the Debugger

That’s not all.

As you might notice on the above screen shot, there is also one helpful breakpoint condition: “Hit count”. You can specify after what number of events a breakpoint will really happen. Very handy if you trace some dynamic event or lots of objects.

4. Don’t step into unwanted functions

How many times have you stepped into a constructor for a string type and then needed to quickly step out? Or when you needed to step into lots of small/library functions before the target method? In most cases it’s a waste of time.

See the following example:

void MyFunc(const string &one, const string &two)
{
    auto res = one + two;
    std::cout << res << "\n";
}
/// ...
MyFunc("Hello ", "World");

And then try to press Ctrl+F11 to step into the call of MyFunc(). Where will the debugger go? I see something like this:

What’s more, if you step out of this and then step into again… you’ll go into the second param constructor. Imagine what happens if you have several parameters. You can be easily frustrated before going into your target method!

In most cases it’s better to just filter out those unwanted methods. It’s very rare the problem you’re trying to catch is in the std::string constructor :)

What to do to filter those basic functions out?

Since VS 2012 there is a simple method to create filters: you need to edit default.natstepfilter

Read here about the method of filtering before VS 2012: How to Not Step Into Functions using the Visual C++ Debugger. In older versions you have to play with registry values most of the time.

Cool stuff:

As a little incentive, the same functionality is greatly simplified in Visual Assist. While Debugging you see VA Step Filter. You can just click on the check box to enable or disable filter for a discovered method. That setting can be global or just for a given project. VA filter setting are custom solution, they don’t merge with default.natstepfilter file.

5. Add helper variables for your objects in debug mode

More data is better then less data! It’s always possible to filter out unwanted messages, but it’s impossible to create data out of nothing. Depending on what you’re doing it might be useful to add some additional variables into your objects. When you’re debugging that variables might bring very important information or just make your life easier.

For example, when you work on Tree structures you’ll probably often need to check pNext, pPrev elements. Often those pointers are placed in some base class like a TreeNode, and if you’re checking MyTreeNode that is three levels of class hierarchy lower it’s a pain to check pNext every time. What if you’ll update MyTreeNode with some additional data from pNext? Then you can easily check that without going through object hierarchies. One disadvantage: how to maintain that additional state? 'pNext might be easily changed, so you would have to make some additional logic to properly sync that. While that’s true in most cases, maybe for debugging you don’t need to have full and perfect solution?

Let me give you an example.

I often work on Tree structures that represents text object. Text object contains lines, and lines contains characters. It was painful to check in what line am I in - what text it contains. Because I had to get the first char from the line, then get the pNext and then I ‘see’ the first two letters of the line so I have a clue what line I’m in. How to make that process a bit easier? I’ve just made strLine and added that to Line. I’m updating that new member from time to time. This might not be a perfect information (it might miss when a letter is added or deleted in one frame, but it would get that info in the next frame). But at least I can quickly get the idea in what text line I am in. Simple and easy! And saves a lot of time.

6. Write custom debugging visualizers

This is a huge topic that I’d just like to introduce:

If you’re unhappy about the view of your objects in the debugger, you might want to write your own visualisers.

Debug Visualizers in Visual C++ 2015

In VS2015 there’s even a new built-in template which can be found under Project->Add New Item->Visual C++->Utility->Debugger visualization file (.natvis)

Techniques

With the basic tools we can compose some more advanced strategies.

7. Lots of objects to investigate?

When you have code that is called for lots of objects it’s hard to go through all the objects and just check them line by line. Think about a unique value that might lead you to the interesting place in the code. Then you can set a conditional break and set condition that catches some range. The smaller the range the better.

For example: often I had to debug code that goes through all the characters in a document. One (special) character was not doing ‘well’. It would be impossible to debug all those character individually. But I knew that this special character has different bounding box size than other letters. So I set a conditional breakpoint and looked for ‘width’ value that might point to my special character (width > usual_char_width). I got only two or three elements to check, so I could quickly investigate what was wrong.

In general, you want to make your available options as narrow as possible so that you have only several (not tens or hundreds) places to debug.

8. Mouse events

Debugging mouse events is especially confusing, because when debugger stops the code, most of the events go away!

Mouse clicks are usually easy: for example if you want to check what code was invoked after mouse clicked on some object. Just break into some OnClick/onMouseDown method.

What about mouse dragging? If the debugger stops then the drag state is lost. In those situations I try to do the following things:

Use good old trace/printf output. While dragging I get a lot of messages that leads to better understanding what’s going on. Without breaking the execution. Probably you want to have short drags operations, otherwise you’ll end up with tons of output to filter. Using that output you can isolate the most important place and focus on that part later.
Use conditional breakpoints in places that you really want to check. For example you rotate the object, and you’ll interested why it unexpectedly change position. You can set a breakpoint on the position members and you’ll get a chance to see what’s going on there. The state after stopping is lost, but at least you could play with the rotation for a while and you get into the potential place in the code. Another idea is to set the condition when obj_rot > some_meaningful_value.
Dragging often happens on a copy of objects. Then after the dragging the real objects are transformed once into the proper state. Maybe you can set breakpoint to look only on the original objects? Maybe there is a separate state in the app that tells this is drag operation happening? Then the debugger will stop at the end of drag operation.

9. Build debug visualizers, tools

This might be an evolution of introducing just a simple variables for debugging. If you’re working with complex object, it’s worthy to have tools that trace the data better. Visual Studio or any other IDE/debugger will help you with general stuff, but since each project is different, it’s useful to have custom solutions.

In games that’s very often situation as I see. You probably have some layer that can be enabled during the game session, it will show game stats, performance data, memory consumption. That can be improved to show more and more stuff - depending on your needs. So I definitely suggest investing in those tools.

Other

10. Debug the Release Build

Release builds are faster because most of the optimizations are enabled. However there is no reason why you couldn’t debug such code. What to do to enable such debugging? It needs the following steps: in VS 2013 and VS 2015:

Set Debug Information Format to C7 compatible (/Z7) or Program Database (/Zi).
Set Enable Incremental Linking to No
Set Generate Debug Info to Yes
Set References to /OPT:REF and Enable COMDAT Folding to /OPT:ICF

11. Speed up debug builds!

Slow debug: Tools->Options->Debugging->General->”Require source files to exactly match the original version” Found at http://www.codeproject.com/Tips/515168/Overlooked-reason-for-debug-step-slow-down-in-Visu
Disable Debug Heap - before VS 2015 You can read about debug heap in my older article: Visual Studio slow debugging and _NO_DEBUG_HEAP. Fortunately in VS2015 this heap is disabled by default, so you shouldn’t be expiriencing those problems.
Control symbol files loading. You can reduce number of loaded symbol files, so the startup will be faster. Read more here: Understanding symbol files and Visual Studio’s symbol settings

Summary

In the article I covered 11 tips that will speed up debugging process. What are the most important items for me? Probably that would be conditional breakpoints, debugging lots of objects and improvements in the debug version of the code. But other elements from the list are also important, so it’s not easy to make a real order here. And often you have to exchange one technique into another one, to suit your needs best.

What’s more, the list is definitely not complete, and many more techniques exists. Maybe you have something to add?

Do you use any special techniques when you debug your apps?
Do you use any custom tools to help debugging?

Examples of Parallel Algorithms From C++17

Bartlomiej Filipek — Mon, 27 Aug 2018 11:17:13 +0000

MSVC (VS 2017 15.8, end of August 2018) is as far as I know the only major compiler/STL implementation that has parallel algorithms. Not everything is done, but you can use a lot of algorithms and apply std::execution::par on them!

Have a look at few examples I managed to run.

Introduction

Parallel algorithms look surprisingly simple from a user point of view. You have a new parameter - called execution policy - that you can pass to most of the std algorithms:

std::algorithm_name(policy, /* normal args... */);

The general idea is that you call an algorithm and then you specify how it can be executed. Can it be parallel, maybe vectorized, or just serial.

We, as authors of the code, only know if there are any side effects, possible race conditions, deadlocks, or if there’s no sense in running it parallel (like if you have a small collection of items).

Execution Policies

The execution policy parameter will tell the algorithm how it should be executed. We have the following options:

sequenced_policy - is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and require that a parallel algorithm’s execution may not be parallelized.
- the corresponding global object is std::execution::seq
parallel_policy - is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm’s execution may be parallelized.
- the corresponding global object is std::execution::par
parallel_unsequenced_policy - is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm’s execution may be parallelized and vectorized.
- the corresponding global object is std::execution::par_unseq

New algorithms

A lot of existing algorithms were updated and overloaded with the execution policy: See the full list here:
Extensions for parallelism - cppreference.com

And we got a few new algorithms:

for_each- similar to std::for_each except returns void.
for_each_n - applies a function object to the first n elements of a sequence.
reduce - similar to std::accumulate, except out of order execution.
exclusive_scan - similar to std::partial_sum, excludes the i-th input element from the i-th sum.
inclusive_scan - similar to std::partial_sum, includes the i-th input element in the i-th sum
transform_reduce - applies a functor, then reduces out of order
transform_exclusive_scan - applies a functor, then calculates exclusive scan
transform_inclusive_scan - applies a functor, then calculates inclusive scan

One of the most powerful algorithms is reduce (and its form of transform_reduce). Briefly, the new algorithm provides a parallel version of std::accumulate.

Accumulate returns the sum of all the elements in a range (or a result of a binary operation that can be different than just a sum).

std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

int sum = std::accumulate(v.begin(), v.end(), /*init*/0);

The algorithm is sequential only; a parallel version will try to compute the final sum using a tree approach (sum sub-ranges, then merge the results, divide and conquer). Such method can invoke the binary operation/sum in a nondeterministic* order. Thus if binary_op is not associative or not commutative, the behaviour is also non-deterministic.

For example, you’ll get the same results for accumulate and reduce for a vector of integers (when doing a sum), but you might get a slight difference for a vector of floats or doubles. That’s because floating point operations are not associative.

transform_reduce will additionally invoke an operation on the input sequence and then perform reduction over the generated results.

MSVC Implementation

In the article: Announcing: MSVC Conforms to the C++ Standard | Visual C++ Team Blog

See the section New Features: Parallel Algorithms:

The following algorithms are parallelized.

adjacent_difference, adjacent_find, all_of, any_of, count, count_if, equal, exclusive_scan, find, find_end, find_first_of, find_if, for_each, for_each_n, inclusive_scan, mismatch, none_of, reduce, remove, remove_if, search, search_n, sort, stable_sort, transform, transform_exclusive_scan, transform_inclusive_scan, transform_reduce

And we might expect more:

No apparent parallelism performance improvement on target hardware; all algorithms which merely copy or permute elements with no branches are typically memory bandwidth limited.

copy, copy_backward, copy_n, fill, fill_n, move, move_backward, remove, remove_if, replace, replace_if, reverse, reverse_copy, rotate, rotate_copy, swap_ranges

Not yet evaluated; parallelism may be implemented in a future release and is suspected to be beneficial.

copy_if, includes, inplace_merge, is_heap, is_heap_until, is_partitioned, is_sorted, is_sorted_until, lexicographical_compare, max_element, merge, min_element, minmax_element, nth_element, partition_copy, remove_copy, remove_copy_if, replace_copy, replace_copy_if, set_difference, set_intersection, set_symmetric_difference, set_union, stable_partition, unique, unique_copy

Anyway, a lot of new algorithms are done, so we can play with reduce, sorting, counting, finding and more.

Examples

All code can be found in my repo:

https://github.com/fenbf/ParSTLTests

I have three examples:

a benchmark with a few algorithms
computing the size of the directory
counting words in a string

A Basic Example

A simple benchmark:

std::vector<double> v(6000000, 0.5);

RunAndMeasure("std::warm up", [&v] {
return std::reduce(std::execution::seq, v.begin(), v.end(), 0.0);
});

RunAndMeasure("std::accumulate", [&v] {
return std::accumulate(v.begin(), v.end(), 0.0);
});

RunAndMeasure("std::reduce, seq", [&v] {
return std::reduce(std::execution::seq, v.begin(), v.end(), 0.0);
});

RunAndMeasure("std::reduce, par", [&v] {
return std::reduce(std::execution::par, v.begin(), v.end(), 0.0);
});

RunAndMeasure("std::reduce, par_unseq", [&v] {
return std::reduce(std::execution::par_unseq, v.begin(), v.end(), 0.0);
});

RunAndMeasure("std::find, seq", [&v] {
auto res = std::find(std::execution::seq, std::begin(v), std::end(v), 0.6);
return res == std::end(v) ? 0.0 : 1.0;
});

RunAndMeasure("std::find, par", [&v] {
auto res = std::find(std::execution::par, std::begin(v), std::end(v), 0.6);
return res == std::end(v) ? 0.0 : 1.0;
});

RunAndMeasure is a helper function that runs a function and then prints the timings. Also, we need to make sure the result is not optimized away.

template <typename TFunc> void RunAndMeasure(const char* title, TFunc func)
{
    const auto start = std::chrono::steady_clock::now();
    auto ret = func();
    const auto end = std::chrono::steady_clock::now();
    std::cout << title << ": " << 
              std::chrono::duration <double, std::milli>(end - start).count() 
              << " ms, res " << ret << "\n";
}

On My machine (Win 10, i7 4720H, 4Cores/8Threads) I get the following results (in Release mode, x86)

std::warm up: 4.35417 ms, res 3e+06
std::accumulate: 6.14874 ms, res 3e+06
std::reduce, seq: 4.07034 ms, res 3e+06
std::reduce, par: 3.22714 ms, res 3e+06
std::reduce, par_unseq: 3.0495 ms, res 3e+06
std::find, seq: 5.13658 ms, res 0
std::find, par: 3.20385 ms, res 0

As you can see there's some speed up!

Computing File Sizes

The below example is based on a code sample from C++17 - The Complete… by Nicolai Josutti.

Parallel algorithms - std::reduce is used to compute sizes of the files in a directory (using recursive scan). It's a nice example of two C++17 features: parallelism and std::filesystem.

Here are the interesting parts of the code:

// Get all the available paths, recursively:
std::vector<std::filesystem::path> paths;
try {
    std::filesystem::recursive_directory_iterator dirpos{ root };
    std::copy(begin(dirpos), end(dirpos),
        std::back_inserter(paths));
}
catch (const std::exception& e) {
    std::cerr << "EXCEPTION: " << e.what() << std::endl;
    return EXIT_FAILURE;
}

Fetching all the paths is handled by so concise code!
For now std::copy cannot be used in a parallel way.

And the final computations:

template <typename Policy>
uintmax_t ComputeTotalFileSize(const std::vector<std::filesystem::path>& paths, 
                               Policy policy)
{
    return std::transform_reduce(
        policy,                                    
        paths.cbegin(), paths.cend(),            // range
        std::uintmax_t{ 0 },                    // initial value
        std::plus<>(),                            // accumulate ...
        [](const std::filesystem::path& p) {    //  file size if regular file
        return is_regular_file(p) ? file_size(p)
            : std::uintmax_t{ 0 };
    });
}

The main invocation:

start = std::chrono::steady_clock::now();
uintmax_t FinalSize = 0;
if (executionPolicyMode)
    FinalSize = ComputeTotalFileSize(paths, std::execution::par);
else
    FinalSize = ComputeTotalFileSize(paths, std::execution::seq);

PrintTiming("computing the sizes", start);

std::cout << "size of all " << paths.size()
            << " regular files: " << FinalSize/1024 << " kbytes\n";

The "problem" I found is that the par and seq policies are not of the same type. That's why I moved the code into a template function and then I could control it via the boolean flag.

Some results (running on the intermediate directory form the builds, 108 files, ~20MB total):

// parallel:
PS D:\github\ParSTLTests\Release> .\FileSizes.exe ..\IntDir\ 1
Using PAR Policy
gathering all the paths: 0.74767 ms
number of files: 108
computing the sizes: 0.655692 ms 
size of all 108 regular files: 20543 kbytes

// sequential:
PS D:\github\ParSTLTests\Release> .\FileSizes.exe ..\IntDir\ 0
Using SEQ Policy
gathering all the paths: 0.697142 ms
number of files: 108
computing the sizes: 1.0994 ms
size of all 108 regular files: 20543 kbytes

For this test, I got 1.0994 ms vs 0.655692 ms - in favour of the PAR version.

Counting Words in a String

The below example comes from Bryce talk about parallel algorithms.

https://www.youtube.com/watch?v=Vck6kzWjY88&t=916s

He showed an interesting way of computing the word count:

In the first phase we transform text into 1 and 0. We want to have 1 in the place where a word starts and 0 in all other places.
- If we have a string "One Two Three" then we want to generate an array 1000100010000.
Then we can reduce the computed array of 1 and 0 - the generated sum is the number of words in a string.

This looks like a "natural" example where transform_reduce might be used:

bool is_word_beginning(char left, char right) 
{ 
    return std::isspace(left) && !std::isspace(right); 
}

template <typename Policy>
std::size_t word_count(std::string_view s, Policy policy)
{
    if (s.empty())
        return 0;

    std::size_t wc = (!std::isspace(s.front()) ? 1 : 0);
    wc += std::transform_reduce(policy,
        s.begin(),
        s.end() - 1,
        s.begin() + 1,
        std::size_t(0),
        std::plus<std::size_t>(),
        is_word_beginning);

    return wc;
}

Here's a benchmark code:

const int COUNT = argc > 1 ? atoi(argv[1]) : 1'000'000;
std::string str(COUNT, 'a');

for (int i = 0; i < COUNT; ++i)
{
    if (i % 5 == 0 || i % 17 == 0)
        str[i] = ' '; // add a space
}

std::cout << "string length: " << COUNT << ", first 60 letters: \n";
std::cout << str.substr(0, 60) << std::endl;

RunAndMeasure("word_count seq", [&str] {
    return word_count(str, std::execution::seq);
});

RunAndMeasure("word_count par", [&str] {
    return word_count(str, std::execution::par);
});

RunAndMeasure("word_count par_unseq", [&str] {
    return word_count(str, std::execution::par_unseq);
});

And some results:

PS D:\github\ParSTLTests\Release> .\WordCount.exe
string length: 1000000, first 60 letters:
 aaaa aaaa aaaa a aa aaaa aaaa aaa  aaaa aaaa aaaa  aaa aaaa
word_count seq: 3.44228 ms, res 223529
word_count par: 1.46652 ms, res 223529
word_count par_unseq: 1.26599 ms, res 223529

PS D:\github\ParSTLTests\Release> .\WordCount.exe 20000000
string length: 20000000, first 60 letters:
 aaaa aaaa aaaa a aa aaaa aaaa aaa  aaaa aaaa aaaa  aaa aaaa
word_count seq: 69.1271 ms, res 4470588
word_count par: 23.342 ms, res 4470588
word_count par_unseq: 23.0487 ms, res 4470588

PS D:\github\ParSTLTests\Release> .\WordCount.exe 50000000
string length: 50000000, first 60 letters:
 aaaa aaaa aaaa a aa aaaa aaaa aaa  aaaa aaaa aaaa  aaa aaaa
word_count seq: 170.858 ms, res 11176471
word_count par: 59.7102 ms, res 11176471
word_count par_unseq: 62.2734 ms, res 11176471

The parallel version is sometimes almost 3x faster! And there are even differences for par_useq.

Summary

I hope you see some potential in the parallel versions of the algorithms. Probably it's not the last word from the MSVC implementation, so maybe we can expect more algorithms and perf boost in the future.

Here's the link to the proposal of Parallel Algorithms: P0024R2

It would be great if other STL implementations catch up:

LLVM libc++ C++1Z Status - so far all of the items for parallelism are not done yet.
GNU libstdc++ C++17 status - not implemented yet

And there are also other implementations, from third party vendors:

It might be interesting to see if MSVC implementation is faster or slower compared to the third party implementations.

Call to action

If you work with Visual Studio, you can copy the examples from the article (or go to my GitHub and download the solution) and report the results that you got. I wonder what's the average speed up that we currently have with the MSVC implementation.

More from the Author

Bartek recently published a book - "C++17 In Detail"- rather than reading the papers and C++ specification drafts, you can use this book to learn the new Standard in an efficient and practical way.

Simplify code with 'if constexpr' in C++17

Bartlomiej Filipek — Mon, 23 Apr 2018 08:39:05 +0000

Before C++17 we had a few, quite ugly looking, ways to write static if (if that works at compile time) in C++: you could use tag dispatching or SFINAE (for example via std::enable_if). Fortunately, that's changed, and we can now take benefit of if constexpr!

Let's see how we can use it and replace some std::enable_if code.

One note: this article comes from my blog: Bartek's coding blog: Simplify code with 'if constexpr' in C++17.

Intro

Static if in the form of if constexpr is an amazing feature that went into C++17. Recently @meeting C++ there was a post where Jens showed how he simplified one code sample using if constexpr: How if constexpr simplifies your code in C++17.

I've found two additional examples that can illustrate how this new feature works:

Number comparisons
Factories with a variable number of arguments

I think those examples might help you to understand the static if from C++17.

But for a start, I'd like to recall the basic knowledge about enable_if to set some background.

Why compile time if?

At first, you may ask, why do we need static if and those complex templated expressions... wouldn't normal if just work?

Here's a test code:

template <typename T>
std::string str(T t)
{
    if (std::is_same_v<T, std::string>) // or is_convertible...
        return t;
    else
        return std::to_string(t);
}

The above routine might be some simple utility that is used to print stuff. As to_string doesn't accept std::string we can test and just return t if it's already a string. Sound simple... but try to compile this code:

// code that calls our function
auto t = str("10"s);

You might get something like this:

In instantiation of 'std::__cxx11::string str(T) [with T = 
std::__cxx11::basic_string<char>; std::__cxx11::string =
 std::__cxx11::basic_string<char>]':
required from here
error: no matching function for call to 
'to_string(std::__cxx11::basic_string<char>&)'
    return std::to_string(t);

is_same yields true for the type we used (string) and we can just return t, without any conversion... so what's wrong?

Here's the main point:

The compiler compiled both branches and found an error in the else case. It couldn't reject "invalid" code for this particular template instantiation.

So that's why we need static if, that would "discard" code and compile only the matching statement.

`std::enable_if`

One way to write static if in C++11/14 is to use enable_if.

enable_if (and enable_if_v since C++14). It has quite strange syntax:

template< bool B, class T = void >  
struct enable_if;

enable_if will evaluate to T if the input condition B is true. Otherwise, it's SFINAE, and a particular function overload is removed from the overload set.

We can rewrite our basic example to:

template <typename T>
std::enable_if_t<std::is_same_v<T, std::string>, std::string> strOld(T t)
{
    return t;
}

template <typename T>
std::enable_if_t<!std::is_same_v<T, std::string>, std::string> strOld(T t)
{
    return std::to_string(t);
}

Not easy... right?

See below how we can simplify such code with if constexpr from C++17. After you read the post, you'll be able to rewrite our str utility quickly.

Use Case 1 - Comparing Numbers

At first, let's start with a simple example: close_enough function, that works on two numbers. If the numbers are not floating points (like when we have two ints), then we can just compare it. Otherwise, for floating points, it's better to use some epsilon.

I've found this sample from at Practical Modern C++ Teaser - a fantastic walkthrough of modern C++ features by Patrice Roy. He was also very kind and allowed me to include this example.

C++11/14 version:

template <class T>
constexpr T absolute(T arg) {
   return arg < 0 ? -arg : arg;
}

template <class T>
constexpr enable_if_t<is_floating_point<T>::value, bool> 
close_enough(T a, T b) {
   return absolute(a - b) < static_cast<T>(0.000001);
}
template <class T>
constexpr enable_if_t<!is_floating_point<T>::value, bool> 
close_enough(T a, T b) {
   return a == b;
}

As you see, there's a use of enable_if. It's very similar to our str function. The code tests if the type of input numbers is is_floating_point. Then, the compiler can remove one function from the overload resolution set.

And now, let's look at the C++17 version:

template <class T>
constexpr T absolute(T arg) {
   return arg < 0 ? -arg : arg;
}

template <class T>
constexpr auto precision_threshold = T(0.000001);

template <class T>
constexpr bool close_enough(T a, T b) {
   if constexpr (is_floating_point_v<T>) // << !!
      return absolute(a - b) < precision_threshold<T>;
   else
      return a == b;
}

Wow... so just one function, that looks almost like a normal function. With nearly "normal" if :)

if constexpr evaluates constexpr expression at compile time and then discards the code in one of the branches.

BTW: Can you see some other C++17 features that were used here?

Play with the code

Go to the main article with a live code example:
Bartek's coding blog: Simplify code with 'if constexpr' in C++17

Use case 2 - factory with variable arguments

In the item 18 of Effective Modern C++ Scott Meyers described a method called makeInvestment:

template<typename... Ts> 
std::unique_ptr<Investment> 
makeInvestment(Ts&&... params);

There's a factory method that creates derived classes of Investment and the main advantage is that it supports a variable number of arguments!

For example, here are the proposed types:

class Investment
{
public:
    virtual ~Investment() { }

    virtual void calcRisk() = 0;
};

class Stock : public Investment
{
public:
    explicit Stock(const std::string&) { }

    void calcRisk() override { }
};

class Bond : public Investment
{
public:
    explicit Bond(const std::string&, const std::string&, int) { }

    void calcRisk() override { }
};

class RealEstate : public Investment
{
public:
    explicit RealEstate(const std::string&, double, int) { }

    void calcRisk() override { }
};

The code from the book was too idealistic, and didn't work - it worked until all your classes have the same number and types of input parameters:

Scott Meyers: Modification History and Errata List for Effective Modern C++:

The makeInvestment interface is unrealistic, because it implies that all derived object types can be created from the same types of arguments. This is especially apparent in the sample implementation code, where are arguments are perfect-forwarded to all derived class constructors.

For example if you had a constructor that needed two arguments and one constructor with three arguments, then the code might not compile:

// pseudo code:
Bond(int, int, int) { }
Stock(double, double) { }
make(args...)
{
  if (bond)
     new Bond(args...);
  else if (stock)
     new Stock(args...)
}

Now, if you write make(bond, 1, 2, 3) - then the else statement won't compile - as there no Stock(1, 2, 3) available! To work, we need something like static if - if that will work at compile time, and will reject parts of the code that don't match a condition.

Some posts ago, with the help of one reader, we came up with a working solution (you can read more in Bartek's coding blog: Nice C++ Factory Implementation 2).

Here's the code that could work:

template <typename... Ts> 
unique_ptr<Investment> 
makeInvestment(const string &name, Ts&&... params)
{
    unique_ptr<Investment> pInv;

    if (name == "Stock")
        pInv = constructArgs<Stock, Ts...>(forward<Ts>(params)...);
    else if (name == "Bond")
        pInv = constructArgs<Bond, Ts...>(forward<Ts>(params)...);
    else if (name == "RealEstate")
        pInv = constructArgs<RealEstate, Ts...>(forward<Ts>(params)...);

    // call additional methods to init pInv...

    return pInv;
}

As you can see the "magic" happens inside constructArgs function.

The main idea is to return unique_ptr<Type> when Type is constructible from a given set of attributes and nullptr when it's not.

Before C++17

In my previous solution (pre C++17) we used std::enable_if and it looked like that:

// before C++17
template <typename Concrete, typename... Ts>
enable_if_t<is_constructible<Concrete, Ts...>::value, unique_ptr<Concrete>>
constructArgsOld(Ts&&... params)
{
    return std::make_unique<Concrete>(forward<Ts>(params)...);
}

template <typename Concrete, typename... Ts>
enable_if_t<!is_constructible<Concrete, Ts...>::value, unique_ptr<Concrete> >
constructArgsOld(...)
{
    return nullptr;
}

std::is_constructible @cppreference.com - allows us to quickly test if a list of arguments could be used to create a given type.

In C++17 there's a helper:

is_constructible_v = is_constructible<T, Args...>::value;

So we could make the code shorter a bit...

Still, using enable_if looks ugly and complicated. How about C++17 version?

With `if constexpr`

Here's the updated version:

template <typename Concrete, typename... Ts>
unique_ptr<Concrete> constructArgs(Ts&&... params)
{ 
   if constexpr (is_constructible_v<Concrete, Ts...>)
      return make_unique<Concrete>(forward<Ts>(params)...);
   else
       return nullptr;
}

We can even extend it with a little logging features, using fold expression:

template <typename Concrete, typename... Ts>
std::unique_ptr<Concrete> constructArgs(Ts&&... params)
{ 
    cout << __func__ << ": ";
    // fold expression:
    ((cout << params << ", "), ...);
    cout << "\n";

    if constexpr (std::is_constructible_v<Concrete, Ts...>)
        return make_unique<Concrete>(forward<Ts>(params)...);
    else
       return nullptr;
}

Cool... right? :)

All the complicated syntax of enable_if went away; we don't even need a function overload for the else case. We can now wrap expressive code in just one function.

if constexpr evaluates the condition and only one block will be compiled. In our case, if a type is constructible from a given set of attributes, then we'll compile make_unique call. If not, then nullptr is returned (and make_unique is not even compiled).

Play with the code

Go to the main article with a live code example:
Bartek's coding blog: Simplify code with 'if constexpr' in C++17

Wrap up

Compile-time if is an amazing feature that greatly simplifies templated code. What's more, it's much expressive and nicer than previous solutions: tag dispatching or enable_if (SFINAE). Now, you can easily express yours intends similarly to "run-time" code.

In this article, we've touched only basic expressions, and as always I encourage you to play more with this new feature and explore.

More from the Author

Bartek recently published a book - "C++17 In Detail"- rather than reading the papers and C++ specification drafts, you can use this book to learn the new

Factory With Self-Registering Types

Bartlomiej Filipek — Mon, 19 Feb 2018 10:37:56 +0000

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? Or when we'd like to make such factory more generic?

Let's see how classes can register themselves in a factory and what are the examples where it's used.

One note: this article comes from my blog: Bartek's coding blog: Factory With Self-Registering Types.

Intro

The code shown as the example at the beginning of this text is not wrong when you have a relatively simple application. For example, in my experiments with pimpl, my first version of the code contained:

static unique_ptr<ICompressionMethod> 
Create(const string& fileName)
{
    auto extension = GetExtension(filename);
    if (extension == "zip")
        return make_unique<ZipCompression>();
    else if (extension = "bz")
        return make_unique<BZCompression>();

    return nullptr;
}

In the above code, I wanted to create ZipCompression or BZCompression based on the extensions of the filename.

That straightforward solution worked for me for a while. Still, if you want to go further with the evolution of the application you might struggle with the following issues:

Each time you write a new class, and you want to include it in the factory you have to add another if in the Create() method. Easy to forget in a complex system.
All the types must be known to the factory
In Create() we arbitrarily used strings to represent types. Such representation is only visible in that single method. What if you'd like to use it somewhere else? Strings might be easily misspelt, especially if you have several places where they are compared.

So all in all, we get strong dependency between the factory and the classes.

But what if classes could register themselves? Would that help?

The factory would just do its job: create new objects based on some matching.
If you write a new class there's no need to change parts of the factory class. Such class would register automatically.

It sounds like an excellent idea.

A practical example

To give you more motivation I'd like to show one real-life example:

Google Test

When you use Google Test library, and you write:

TEST(MyModule, InitTest)
{
}

Behind this single TEST macro a lot of things happen!

For starters your test is expanded into a separate class - so each test is a new class.

But then, there's a problem: you have all the tests, so how the test runner knows about them?

It's the same problem were' trying to solve in this post. The classes need to be registered.

Have a look at this code: from googletest/.../gtest-internal.h:

// (some parts of the code cut out)
#define GTEST_TEST_(test_case_name, test_name, parent_class, parent_id)\
class GTEST_TEST_CLASS_NAME_(test_case_name, test_name) \
: public parent_class \
{\
  virtual void TestBody();\
  static ::testing::TestInfo* const test_info_ GTEST_ATTRIBUTE_UNUSED_;\
};\
\
::testing::TestInfo* const GTEST_TEST_CLASS_NAME_(test_case_name, test_name)\
  ::test_info_ =\
    ::testing::internal::MakeAndRegisterTestInfo(\
        #test_case_name, #test_name, NULL, NULL, \
        new ::testing::internal::TestFactoryImpl<\
            GTEST_TEST_CLASS_NAME_(test_case_name, test_name)>);\
void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody()

I cut some parts of the code to make it shorter, but basically GTEST_TEST_ is used in TEST macro and this will expand to a new class. In the lower section, you might see a name MakeAndRegisterTestInfo. So here's the place where the class registers!

After the registration, the runner knows all the existing tests and can invoke them.

When I was implementing a custom testing framework for one of my projects I went for a similar approach. After my test classes were registered, I could filter them, show their info and of course be able to execute the test suits.

I believe other testing frameworks might use a similar technique.

Flexibility

My previous example was related to unknown types: for tests, you know them at compile time, but it would be hard to list them in one method create.

Still, such self-registration is useful for flexibility and scalability. Even for my two classes: BZCompression and ZipCompression.

Now when I'd like to add a third compression method, I just have to write a new class, and the factory will know about it - without much of intervention in the factory code.

Ok, ok... we've discussed some examples, but you probably want to see the details!

So let's move to the actual implementation.

Self-registration

What do we need?

Some Interface - we'd like to create classes that are derived from one interface. It's the same requirement as a "normal" factory method.
Factory class that also holds a map of available types
A proxy that will be used to create a given class. The factory doesn't know how to create a given type now, so we have to provide some proxy class to do it.

For the interface we can use ICompressionMethod:

class ICompressionMethod
{
public:
    ICompressionMethod() = default;
    virtual ~ICompressionMethod() = default;

    virtual void Compress() = 0;
};

And then the factory:

class CompressionMethodFactory
{
public:
    using TCreateMethod = unique_ptr<ICompressionMethod>(*)();

public:
    CompressionMethodFactory() = delete;

    static bool Register(const string name, TCreateMethod funcCreate);

    static unique_ptr<ICompressionMethod> Create(const string& name);

private:
    static map<string, TCreateMethod> s_methods;
};

The factory holds the map of registered types. The main point here is that the factory uses now some method (TCreateMethod) to create the desired type (this is our proxy). The name of a type and that creation method must be initialized in a different place.

The implementation of such factory:

map<string, TCreateMethod> CompressionMethodFactory::s_methods;

bool CompressionMethodFactory::Register(const string name, 
                                        TCreateMethod& funcCreate)
{
    if (auto it = s_methods.find(name); it == s_methods.end())
    { // C++17 init-if ^^
        s_methods[name] = funcCreate;
        return true;
    }
    return false;
}

unique_ptr<ICompressionMethod> 
CompressionMethodFactory::Create(const string& name)
{
    if (auto it = s_methods.find(name); it != s_methods.end()) 
        return it->second(); // call the createFunc

    return nullptr;
}

Now we can implement a derived class from ICompressionMethod that will register in the factory:

class ZipCompression : public ICompressionMethod
{
public:
    virtual void Compress() override;

    static unique_ptr<ICompressionMethod> CreateMethod() { 
        return smake_unique<ZipCompression>();
    }
    static std::string GetFactoryName() { return "ZIP"; }

private:
    static bool s_registered;
};

The downside of self-registration is that there's a bit more work for a class. As you can see we have to have a static CreateMethod defined.

To register such class all we have to do is to define s_registered:

bool ZipCompression::s_registered =
  CompressionMethodFactory::Register(ZipCompression::GetFactoryName(),   
                                     ZipCompression::CreateMethod);

The basic idea for this mechanism is that we rely on static variables. They will be initialized before main() is called.

But can we be sure that all of the code is executed, and all the classes are registered? s_registered is not used anywhere later, so maybe it could be optimized and removed? And what about the order of initialization?

Static var initialization

We might run into two problems:

Order of static variables initialization:

It's called "static initialization order fiasco" - it's a problem where one static variable depends on another static variable. Like static int a = b + 1 (where b is also static). You cannot be sure b will be initialized before a. Bear in mind that such variables might be in a different compilation unit.

Fortunately, for us, it doesn't matter. We might end up with a different order of elements in the factory container, but each name/type is not dependent on other already registered types.

But what about the first insertion? Can we be sure that the map is created and ready for use?

To be certain I've even asked a question at SO:
C++ static initialization order: adding into a map - Stack Overflow

Our map is defined as follows:

map<string, TCreateMethod> CompressionMethodFactory::s_methods;

And that falls into the category of Zero initialization. Later, the dynamic initialization happens - in our case, it means all s_registered variables are inited.

So it seems we're safe here.

You can read more about it at isocpp FAQ and at cppreference - Initialization.

Can `s_registered` be eliminated?

Fortunately, we're also on the safe side:

From the latest draft of C++: n4713.pdf [basic.stc.static], point 2:

variable with static storage duration has initialization or a destructor with side effects; it shall not be eliminated even if it appears to be unused.

So the compiler won't optimize such variable.

Although this might happen when we use some templated version... but more on that later.

Update: and read what can happen when your symbols comes from a static library: my newest post: Static Variables Initialization in a Static Library, Example

Extensions

All in all, it seems that our code should work! :)

For now, I've only shown a basic version, and we can think about some updates:

Proxy classes

In our example, I've used only a map that holds <name, TCreateMethod - this works because all we need is a way to create the object.

We can extend this and use a "full" proxy class that will serve as "meta" object for the target type.

In my final app code I have the following type:

struct CompressionMethodInfo
{
    using TCreateMethod = std::unique_ptr<ICompressionMethod>(*)();
    TCreateMethod m_CreateFunc;
    string m_Description;
};

Beside the creation function, I've added m_Description. This addition enables to have a useful description of the compression method. I can then show all that information to the user without the need to create real compression methods.

The factory class is now using

static map<string, CompressionMethodInfo> s_methods;

And when registering the class, I need to pass the info object, not just the creation method.

bool ZipCompression::s_registered =
  CompressionMethodFactory::Register(
      ZipCompression::GetFactoryName(), 
      { ZipCompression::CreateMethod, 
        "Zip compression using deflate approach" 
      });

Templates

As I mentioned the downside of self-registration is that each class need some additional code. Maybe we can pack it in some RegisterHelper<T> template?

Here's some code (with just creation method, not with the full info proxy class):

template <typename T>
class RegisteredInFactory
{
protected:
    static bool s_bRegistered;
};

template <typename T>
bool RegisteredInFactory<T>::s_bRegistered = 
CompressionMethodFactory::Register(T::GetFactoryName(), T::CreateMethod);

The helper template class wraps s_bRegistered static variable and it registers it in the factory. So now, a class you want to register just have to provide T::GetFactoryName and T::CreateMethod:

class ZipCompression : public ICompressionMethod, 
                       public RegisteredInFactory<ZipCompression>
{
public:
    virtual void Compress() override { /*s_bRegistered;*/ }

    static unique_ptr<ICompressionMethod> CreateMethod() { ... }
    static std::string GetFactoryName() { return "ZIP"; }
};

Looks good... right?

But when you run it the class is not being registered!

Have a look at this code @coliru.

But if you uncomment /*s_bRegistered*/ from void Compress() the registration works fine.

Why is that?

It seems that although s_bRegistered is also a static variable, it's inside a template. And templates are instantiated only when they are used (see odr-use @stackoverlow). If the variable is not used anywhere the compiler can remove it...

Another topic that's worth a separate discussion.

So all in all, we have to be smarter with the templated helper. I'll have to leave it for now.

Not using strings a name

I am not happy that we're still using string to match the classes.

Still, if used with care strings will work great. Maybe they won't be super fast to match, but it depends on your performance needs. Ideally, we could think about unique ids like ints, hashes or GUIDs.

Some articles to read and extend

Summary

In this post, I've covered a type of factory where types register themselves. It's an opposite way of simple factories where all the types are declared upfront.

Such approach gives more flexibility and removes dependency on the exact list of supported classes from the factory.

The downside is that the classes that want to register need to ask for it and thus they need a bit more code.

Let me know what do you think about self-registration? Do you use it in your projects? Or maybe you have some better ways?

Call To Action

If you like more programming stories from me, just signup to my weekly newsletter: Bartek's coding blog newsletter
(You'll also get some C++ bonuses)

How a weak_ptr might prevent full memory cleanup of managed object

Bartlomiej Filipek — Tue, 30 Jan 2018 13:48:40 +0000

When I was working on the C++ 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.

Let's drill down the case. It might be interesting as we'll learn how shared/weak pointers interact with each other.

One note: this article comes from my blog: Bartek's coding blog: How a weak_ptr might prevent full memory cleanup of managed object.

The case

Ok, so what's the problem?

First, we need to see the elements of the case:

a managed object, let's assume it's big
- here we care about objects with a large "sizeof()" (as noted in one comment). For example if a class uses some standard containers they will probably allocate separate chunks of memory.
shared_ptr (one or more) - they point to the above object (resource)
make_shared - used to create a shared pointer
weak_ptr
the control block of shared/weak pointers

The code is simple:

Shared pointers to our large object go out of the scope. The reference counter reaches 0, and the object can be destroyed. But there's also one weak pointer that outlives shared pointers.

weak_ptr<MyLargeType> weakPtr;
{
    auto sharedPtr = make_shared<MyLargeType>();
    weakPtr = sharedPtr;
    // ...
}
cout << "scope end...\n";

In the above code we have two scopes: inner - where the shared pointer is used, and outer - with a weak pointer (notice that this weak pointer holds only a 'weak' reference, it doesn't use lock() to create a strong reference).

When the shared pointer goes out the scope of the inner block it should destroy the managed object... right?

This is important: when the last shared pointer is gone this destroys the objects in the sense of calling the destructor of MyLargeType... but what about the allocated memory? Can we also release it?

To answer that question let's consider the second example:

weak_ptr<MyLargeType> weakPtr;
{
    shared_ptr<MyLargeType> sharedPtr(new MyLargeType());
    weakPtr = sharedPtr;
    // ...
}
cout << "scope end...\n";

Almost the same code... right? The difference is only in the approach to create the shared pointer: here we use explicit new.

Let's see the output when we run both of those examples.

In order to have some useful messages, I needed to override global new and delete, plus report when the destructor of my example class is called.

void* operator new(size_t count) {
    cout << "allocating " << count << " bytes\n";
    return malloc(count);
}

void operator delete(void* ptr) noexcept {
    cout << "global op delete called\n";
    free(ptr);
}

struct MyLargeType {
    ~MyLargeType () { cout << "destructor MyLargeType\n"; }

private: 
    int arr[100]; // wow... so large!!!!!!
};

Ok, ok... let's now see the output:

For make_shared:

allocating 416 bytes
destructor MyLargeType
scope end...
global op delete called

and for the explicit new case:

allocating 400 bytes
allocating 24 bytes
destructor MyLargeType
global op delete called
scope end...
global op delete called

What happens here?

The first important observation is that, as you might already know, make_shared will perform just one memory allocation. With the explicit new we have two separate allocations.

So we need a space for two things: the object and... the control block.

The control block is implementation depended, but it holds the pointer to an object and also the reference counter. Plus some other things (like custom deleter, allocator, ...).

When we use explicit new, we have two separate blocks of memory. So when the last shared pointer is gone, then we can destroy the object and also release the memory.

So we see the output:

destructor MyLargeType
global op delete called

Both the destructor and free() is called - before the scope ends.

However, when a shared pointers is created using make_shared() then the managed object resides in the same memory block as the rest of the implementation details.

Here's a picture with that idea:

The thing is that when you create a weak pointer, then inside the control block "weak counter" is usually increased. Weak pointers and shared pointers need that mechanism so that they can answer the question "is the pointer dead or not yet" (or to call expire() method.

In other words we cannot remove the control block if there's a weak pointer around (while all shared pointers are dead). So if the managed object is allocated in the same memory chunk, we cannot release memory for it as well - we cannot free just part of the memory block (at least not that easily).

As noted in one comment: classes that uses separate memory

Below you can find some code from MSVC implementation, this code is called from the destructor of shared_ptr (when it's created from make_shared):

~shared_ptr() _NOEXCEPT
{   // release resource
    this->_Decref();
}

void _Decref()
{    // decrement use count
    if (_MT_DECR(_Uses) == 0)
    {    // destroy managed resource, 
        // decrement weak reference count
        _Destroy();
        _Decwref();
    }
}

void _Decwref()
{    // decrement weak reference count
    if (_MT_DECR(_Weaks) == 0)
    {
        _Delete_this();
    }
}

As you see there's separation of Destroying the object - that only calls destructor, and Delete_this() - only occurs when the weak count is zero.

Here's the link to coliru if you want to play with the code: Coliru example.

Fear not!

The story of memory allocations and clean up is interesting... but does it affect us that much?

Possibly not much.

You shouldn't stop using make_shared just because of that reason! :)

The thing is that it's quite a rare situation.

Still, it's good to know this behaviour and keep it in mind when implementing some complex systems that rely on shared and weak pointers.

For example, I am thinking about the concurrent weak dictionary data structure presented by Herb Sutter: My Favorite C++ 10-Liner | GoingNative 2013 | Channel 9.

Correct me if I'm wrong:

make_shared will allocate one block of memory for the control block and for the widget. So when all shared pointers are dead, the weak pointer will live in the cache... and that will also cause the whole memory chunk to be there as well. (Destructors are called, but memory cannot be released).

To enhance the solution, there should be some additional mechanism implemented that would clean unused weak pointers from time to time.

Remarks

After I understood the case I also realized that I'm a bit late with the explanation - others have done it in the past :) Still, I'd like to note things down.

So here are some links to resources that also described the problem:

Effective Modern C++ - item 21 - "Prefer std::make_unique and std::make_shared to direct use of new."
Make_shared, almost a silver bullet | I will not buy this blog, it is scratched!.

From Effective Modern C++, page 144:

As long as std::weak_ptrs refer to a control block (i.e., the weak count is greater than zero), that control block must continue to exist. And as long as a control block exists, the memory containing it must remain allocated. The memory allocated by a std::shared_ptr make function, then, can’t be deallocated until the last std::shared_ptr and the last std::weak_ptr referring to it have been destroyed.

Summary

The whole article was a fascinating investigation to do!

Sometimes I catch myself spending too much time on things that maybe are not super crucial. Still, they are engaging. It's great that I can share this as a blog post :)

The bottom line for the whole investigation is that the implementation of shared and weak pointers is quite complex. When the control block is allocated in the same memory chunk as the managed object, a special care have to be taken when we want to release the allocated memory.

BTW: once again here's the link to C++ Smart Pointers Reference Card if you like to download it.

How to improve functions with toggle params?

Bartlomiej Filipek — Fri, 10 Nov 2017 11:26:25 +0000

How to improve the code around functions like:

RenderGlyphs(true, false, true, false);

It's not easy to reason about those true/false params.

We'd like not only to have more expressive code but to have safer code.

For example, what if you mix two parameters and change their order? The compiler won't help you much!

We could add comments:

RenderGlyphs(glyphs,
             /*useChache*/true, 
             /*deferred*/false, 
             /*optimize*/true, 
             /*finalRender*/false);

And although the above code is a bit more readable, still we don't get any more safety.

So what can we do more?

Note: The article originally eppeared on my blog as: Bartek's coding blog: On Toggle Parameters.

Ideas

Here are some ideas that you can use to make such code better:

Small Enums

In theory we could write the following declarations:

enum class UseCacheFlag    { True, False };
enum class DeferredFlag    { True, False };
enum class OptimizeFlag    { True, False };
enum class FinalRenderFlag { True, False };

// and call like:
RenderGlyphs(glyphs,
             UseCacheFlag::True, 
             DeferredFlag::False, 
             OptimizeFlag::True, 
             FinalRenderFlag::False);

Using enums is a great approach but have some disadvantages:

A lot of additional names required!
- Maybe we could reuse some types, should we have some common flags defined in the project? how to organize those types?
Values are not directly convertible to bool, so you have to compare against Flag::True explicitly inside the function body.

The required explicit comparison was the reason Andrzej wrote his own little library that creates toggles with conversion to bool.

Initially, I though it's a disappointing that we don't have direct support from the language. But after a while, I changed my mind. The explicit comparison is not that hard to write, so maybe it would be overkill to include it in the language spec? Introducing explicit casts might even cause some problems.

Still, I am not quite happy with the need to write so many tiny enums... And since I am lazy I probably won't apply such rule to all of my code :)

Param Structure

If you have several parameters (like 4 or 5, depends on the context) why don't wrap them into a separate structure?

struct RenderGlyphsParam
{
    bool useCache;
    bool deferred;
    bool optimize;
    bool finalRender;
};
void RenderGlyphs(Glyphs &glyphs, const RenderGlyphsParam &renderParam);

// the call:
RenderGlyphs(glyphs,
             {/*useChache*/true, 
             /*deferred*/false, 
             /*optimize*/true, 
             /*finalRender*/false});

OK... this didn't help much! You get additional code to manage, and the caller uses almost the same code.

So why could it help?

It moves the problem to the other place. You could apply strong types to individual members of the structure.
If you need to add more parameters then you can just extend the structure.
Especially useful if more functions can share such param structure.

BTW: you could put the glyphs variable also in the RenderGlyphsParam, this is only for example.

Eliminate

We could try to fix the syntax and use clever techniques. But what about using a simpler method? What if we provide more functions and just eliminate the parameter?

It's ok to have one or maybe two toggle parameters, but if you have more maybe it means a function tries to do too much?

In our simple example we could try:

RenderGlyphsDeferred(glyphs,
             /*useChache*/true, 
             /*optimize*/true);
RenderGlyphsForFinalRender(glyphs,
             /*useChache*/true, 
             /*optimize*/true;

We can make the change for parameters that are mutually exclusive. In our example, deferred cannot happen together with the final run.

You might have some internal function RenderGlyphsInternal that would still take those toggle parameters (if you really cannot separate the code). But at least such internal code will be hidden from the public API. You can refactor that internal function later if possible.

So I think it's good to look at the function declaration and review if there are mutually exclusive parameters. Maybe the function is doing too much? If yes, then cut it into several smaller functions.

After writing this section I've noticed a tip from Martin Fowler on Flag Arguments. In the text he also tries to avoid toggles.

You can also read this article from Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments. And more in his book Clean Code: A Handbook of Agile Software Craftsmanship

What's in future C++2z?

There's a paper: Designated Initialization, P0329R0 that might go into C++20.

Basically you could use similar approach as in C99 and name arguments that you pass to a function:

copy(.from = a, .to = b);

There's even a CLang implementation already, see this: Uniform designated initializers and arguments for C++.

Stronger Types

Using small enums or structures is a part of a more general topic of using Stronger Types. Similar problems might appear when you have several ints as parameters or strings...

You can read more about:

One example

Recently, I had a chance to apply some ideas of enum/stronger types to my code. Here's a rough outline:

// functions:
bool CreateContainer(Container *pContainer, bool *pOutWasReused);

void Process(Container *pContainer, bool bWasReused);

// usage
bool bWasReused = false;
if (!CreateContainer(&myContainer, &bWasReused))
   return false;

Process(&myContainer, bWasReused);

Briefly: we create a container, and we process it. But the container might be reused (some pool, reusing existing object, etc., some internal logic).

I thought that it doesn't look nice. We use one output flag and then it's passed as input flag to some other function.

What's more, we pass a pointer, so some additional validation should happen. Also, the output parameters are discouraged in modern C++, so it's not good to have them anyway.

How can we do better?

Let's use enums!

enum class ContainerCreateInfo { Err, Created, Reused };
ContainerCreateInfo CreateContainer(Container *pContainer);

void Process(Container *pContainer, ContainerCreateInfo createInfo);

// usage
auto createInfo = CreateContainer(&myContainer)
if (createInfo == ContainerCreateInfo::Err);
   return false;

Process(&myContainer, createInfo);

Isn't it better?

There are no outputs via pointer stuff here; we have a strong type for the 'toggle' parameter.

Also, if you need to pass some more information in that CreateInfo enum you can just add one more enum value and process it in proper places, the function prototypes don't have to change.

Of course in the implementation, you have to compare against enum values (not just cast to bool), but itis not difficult and even more verbose.

Summary

Toggle params are not totally wrong, and it's probably impossible to avoid them entirely. Still, it's better to review your design when you want to add third or fourth parameter in a row :)

Maybe you can reduce the number of toggles/flags and have more expressive code?

Some questions to you:

Do you try to refactor toggle parameters?
Do you use strong types in your code?

Call To Action

If you like more programming stories from me, just signup to my weekly newsletter: Bartek's coding blog newsletter
(You'll also get some C++17 bonuses)

Curious case of branch performance

Bartlomiej Filipek — Tue, 31 Oct 2017 22:37:41 +0000

When doing my last performance tests for bool packing, I got strange results sometimes. It appeared that one constant generated different results than the other. Why was that? Let's have a quick look at branching performance.

The problem

Just to recall (first part, second part) I wanted to pack eight booleans (results of a condition) into one byte, 1 bit per condition result. The problem is relatively simple, but depending on the solution you might write code that's 5x...8x times slower than the baseline version.

Let's take a simple version that uses std::vector<bool>:

static const int ThresholdValue = X;
std::unique_ptr<int[]> inputValues = PrepareInputValues();
std::vector<bool> outputValues;

outputValues.resize(experimentValue);

// start timer
{
    for (size_t i = 0; i < experimentValue; ++i)
        outputValues[i] = inputValues[i] > ThresholdValue;
}
// end timer

And see the results:

The chart shows timings for 100 samples taken from running the code, vector size (experimentValue) is 1mln. The lower the better.

Do you know what the difference between the above results is?

It's only X - the value of ThresholdValue!

If it's 254 then you got the yellow performance, if it's 127, then you got those green, blue squares. The generated code is the same, so why we see the difference? The same code can run eve 4x slower!

So maybe vector implementation is wrong?

Let's use a (not optimal) manual version:

uint8_t OutByte = 0;
int shiftCounter = 0;

for (int i = 0; i < experimentValue; ++i)
{
    if (*pInputData > Threshold)
        OutByte |= (1 << shiftCounter);

    pInputData++;
    shiftCounter++;

    if (shiftCounter > 7)
    {
        *pOutputByte++ = OutByte;
        OutByte = 0;
        shiftCounter = 0;
    }
}

And the results:

Again, when running with Threshold=127, you get the top output, while Threshold=254 returns the bottom one.

OK, but also some of the versions of the algorithm didn't expose this problem.

For example, the optimized version. That packed 8 values at 'once'.

uint8_t Bits[8] = { 0 };
const int64_t lenDivBy8 = (experimentValue / 8) * 8;

for (int64_t j = 0; j < lenDivBy8; j += 8)
{
    Bits[0] = pInputData[0] > Threshold ? 0x01 : 0;
    Bits[1] = pInputData[1] > Threshold ? 0x02 : 0;
    Bits[2] = pInputData[2] > Threshold ? 0x04 : 0;
    Bits[3] = pInputData[3] > Threshold ? 0x08 : 0;
    Bits[4] = pInputData[4] > Threshold ? 0x10 : 0;
    Bits[5] = pInputData[5] > Threshold ? 0x20 : 0;
    Bits[6] = pInputData[6] > Threshold ? 0x40 : 0;
    Bits[7] = pInputData[7] > Threshold ? 0x80 : 0;

    *pOutputByte++ = Bits[0] | Bits[1] | Bits[2] | Bits[3] | 
                     Bits[4] | Bits[5] | Bits[6] | Bits[7];
    pInputData += 8;
}

The samples are not lining up perfectly, and there are some outliers, but still, the two runs are very similar.

And also the baseline (no packing at all, just saving into bool array)

std::unique_ptr<uint8_t[]> outputValues(new uint8_t[experimentValue]);

// start timer
{
    for (size_t i = 0; i < experimentValue; ++i)
        outputValues[i] = inputValues[i] > ThresholdValue;
});
// end timer

This time, Threshold=254 is slower... but still not that much, only few percents. Not 3x...4x as with the first two cases.

What's the reason for those results?

The test data

So far I didn't explain how my input data are even generated. Let's unveil that.

The input values simulate greyscale values, and they are ranging from 0 up to 255. The threshold is also in the same range.

The data is generated randomly:

std::mt19937 gen(0);
std::uniform_int_distribution<> dist(0, 255);

for (size_t i = 0; i < experimentValue; ++i)
    inputValues[i] = dist(gen);

Branching

As you might already discover, the problem lies in the branching (mis)predictions. When the Threshold value is large, there's little chance input values will generate TRUE. While for Threshold = 127 we get 50% chances (still it's a random pattern).

Here's a great experiment that shows some problems with branching: Fast and slow if-statements: branch prediction in modern processors @igoro.com. And also Branch predictor - Wikipedia.

For a large threshold value, most of my code falls into FALSE cases, and thus no additional instructions are executed. CPU sees this in it's branch history and can predict the next operations. When we have random 50% pattern, the CPU cannot choose the road effectively, so there are many mispredictions.

Unfortunately, I don't have tools to measure those exact numbers, but for me, it's a rather clear situation. Maybe you can measure the data? Let me know!

But why the other code - the optimized version didn't show the effect? Why it runs similarly, no matter what the constant is?

Details

Let's look at the generated assembly: play @ godbolt.org.

Optimized version (From MSVC)

$LL4@Foo:
        cmp      DWORD PTR [ecx-8], 128   ; 00000080H
        lea      edi, DWORD PTR [edi+1]
        lea      ecx, DWORD PTR [ecx+32]
        setg     BYTE PTR _Bits$2$[esp+8]
        cmp      DWORD PTR [ecx-36], 128  ; 00000080H
        setle    al
        dec      al
        and      al, 2
        cmp      DWORD PTR [ecx-32], 128  ; 00000080H
        mov      BYTE PTR _Bits$1$[esp+8], al
        setle    bh
        dec      bh
        and      bh, 4
        cmp      DWORD PTR [ecx-28], 128  ; 00000080H
        setle    dh
        dec      dh
        and      dh, 8
        cmp      DWORD PTR [ecx-24], 128  ; 00000080H
        setle    ah
        dec      ah
        and      ah, 16             ; 00000010H
        cmp      DWORD PTR [ecx-20], 128  ; 00000080H
        setle    bl
        dec      bl
        and      bl, 32             ; 00000020H
        cmp      DWORD PTR [ecx-16], 128  ; 00000080H
        setle    al
        dec      al
        and      al, 64             ; 00000040H
        cmp      DWORD PTR [ecx-12], 128  ; 00000080H
        setle    dl
        dec      dl
        and      dl, 128              ; 00000080H
        or       dl, al
        or       dl, bl
        or       dl, ah
        or       dl, dh
        or       dl, bh
        or       dl, BYTE PTR _Bits$2$[esp+8]
        or       dl, BYTE PTR _Bits$1$[esp+8]
        mov      BYTE PTR [edi-1], dl
        sub      esi, 1
        jne      $LL4@Foo
        pop      esi
        pop      ebx

And for first manual version: https://godbolt.org/g/csLeHe

        mov      edi, DWORD PTR _len$[esp+4]
        test     edi, edi
        jle      SHORT $LN3@Foo
$LL4@Foo:
        cmp      DWORD PTR [edx], 128     ; 00000080H
        jle      SHORT $LN5@Foo
        movzx    ecx, cl
        bts      ecx, eax
$LN5@Foo:
        inc      eax
        add      edx, 4
        cmp      eax, 7
        jle      SHORT $LN2@Foo
        mov      BYTE PTR [esi], cl
        inc      esi
        xor      cl, cl
        xor      eax, eax
$LN2@Foo:
        sub      edi, 1
        jne      SHORT $LL4@Foo
$LN3@Foo:
        pop      edi
        pop      esi
        ret      0

As we can see the optimized version doesn't use branching. It uses setCC instruction, but this is not a real branch. Strangely GCC doesn't use this approach and uses branches so that the code could be possibly slower.

SETcc – sets the destination register to 0 if the condition is not met and to 1 if the condition is met.

Great book about perf:Branch and Loop Reorganization to Prevent Mispredicts | Intel® Software

See also this explanation for avoiding branches: x86 Disassembly/Branches wikibooks

So, if I am correct, this is why the optimized version doesn't show any effects of branch misprediction.

The first, non-optimal version of the code contains two jumps in the loop, so that's why we can experience the drop in performance.

Still, bear in mind that conditional moves are not always better than branches. For example read more details at Krister Walfridsson's blog: like The cost of conditional moves and branches.

Summary

Things to remember:

Doing performance benchmarks is a really delicate thing.
Look not only at the code but also on the test data used - as different distribution might give completely different results.
Eliminate branches as it might give a huge performance boost!

Charts made with Nonius library, see more about in my micro-benchmarking library blog post.

A question to you:

How do you reduce branches in your perf critical code?

Call To Action

If you like more stories from me, just signup to my weekly newsletter: Bartek's coding blog newsletter
(You'll also get some C++17 bonuses)

Please declare your variables as const

Bartlomiej Filipek — Thu, 20 Jul 2017 11:20:57 +0000

I need to confess that for the last few years I’ve been a bit obsessed with the idea of making all variables const. Whenever I declare a variable in a function body, I try to think if I can make it constant. Let me explain why I think you should be doing the same.

Note: This post was originally posted at my blog: Bartek's coding blog: Please declare your variables as const.

What’s wrong?

What’s wrong with the following code?

int myVariable = 0;

// some code...

myVariable = ComputeFactor(params...);

Versus:

// some code...

const int myVariable = ComputeFactor(params...);

In the first sample, we’re just changing the value of some variable, and that’s typical thing in the code… isn’t it?

Let’s go through the list of benefits of the second approach.

Please note that I’ll focus only on variables used in function bodies, not parameters of functions, or class members.

Why it helps

Performance?

Several years ago, my colleague suggested using const for variables. I thought the only reason for this was optimization and performance. Later, I understood that’s it’s not that obvious, and there are far more important reasons for using const.

In fact, a good C++ compiler can do the same kind of optimization no matter you use const or not. The compiler will deduce if a variable is changed or just initialized once at the start. So, is there any performance benefit here?

It’s hard to show the real numbers here. Ideally, we could get a C++ project (let say minimum 10k LOC) and then use const whenever possible, and compare it against the same project without const.

In a synthetic, small examples like:

string str;
str = "Hello World";

const string str = "Hello World";

There can be a performance increase of even 30%! Numbers from J. Turner talk “Practical Performance Practices”. As one commenter noticed: the gain comes not from the const itself, but from the fact that we're not reassigning the value.

As we can see, there’s a potential in getting some performance, but I wouldn’t expect much across the whole project. It depends on the context. Maybe something like 1…or 2% max. As usual: measure measure measure! :)

Still, why not making life much easier for the compiler and have better code.

So, it seems that the "performance" is not the strongest reason for using const, read below for far more important aspects:

Variables are declared local to their use

If you want to declare a constant variable, you need to have all the required data available. That means you cannot just declare it at the beginning of a function (like in standard old C-way). Thus, it’s a higher chance to have variables quite local to their actual usage.

void foo(int param)
{
    const int otherVariable = Compute(param);
    // code...

    // myVar cannot be declared before 'otherVariable'
    const int myVar = param * otherVariable; 
}

Declaring variables local to their use is not only a good practice but can result in less memory usage (since not all variables might be allocated) and even safer code.

Clear Intent

When you declare something as constant you make it clear “I won’t change the value of that variable.”

Such practice is vital when you read the code. For example:

int myVar = 0;

// code...

// code...

When you see such a thing, you’re not sure if myVar will change or not. It might not be a problem in small functions, but what about longer, complex methods?

While having:

const int myVar = ...;

// code...

You’re at least sure that nothing happens with myVar. You get one parameter less to track.

Clean Code

Sometimes the initialization of a variable won’t be just a simple assignment. Several lines (or more) might be used to give a proper value. In that case making the variable const will force you to move such initialization to a separate place.

As I described in IIFE for Complex Initialization you might enclose the initialization in IIFE or a different method. Anyway, you’ll avoid code looking like that:

int myVariable = 0;

// code... 

// complex initialization of 'myVariable'
if (bCondition)
    myVariable = bCond ? computeFunc(inputParam) : 0;
else
    myVariable = inputParam * 2;

// more code of the current function...

No matter what you use, you’ll end up with only one place where the variable gets its value.

Fewer bugs

When a variable is const you cannot change it, so some unwanted bugs are less likely to happen.

Accidental problems might easily happen when there’s some long function and variables tend to be reused in some cases. You change the value of a variable, and it works for your case, but the old case where it was used now stops working. Again, declaring a variable as const will at least protect you from such stupid bugs. Not to mention that debugging such errors might be a real pain.

BTW: for an example please see this blog posts from Andrzej Krzemienski: More const – fewer bugs

Moving towards functional languages

Functional style is probably a topic worth a separate article, but in general having immutable objects is an essential thing in functional languages.

Immutable objects are thread safe by their nature. When a thread processes that kind of objects, we can be sure that no other threads are changing the objects. Lots of data races can be avoided. That opens many ways to parallelize the algorithm relatively easy.

Because others says so

From C++ Core Guidelines (Con: Constants and Immutability)

Con.1: By default, make objects immutable Reason

Immutable objects are easier to reason about, so make object non-const

only when there is a need to change their value. Prevents accidental

or hard-to-notice change of value.

And

Con.4: Use const to define objects with values that do not change

after construction Reason

Prevent surprises from unexpectedly changed object values.

From Effective C++ by Scott Meyers (chapter 3):

Use const whenever possible.

The wonderful thing about const is that it allows you to specify a semantic constraint - a particular object should not be modified - and

compilers will enforce that constraint. It allows you to communicate

to both compilers and other programmers that a value should remain

invariant. Whenever that is true, you should be sure to say so,

because that way you enlist your compilers’ aid in making sure the

constraint isn’t violated.

Jason Turner:

Exceptions

â€˜A constant variable’ isn’t that an oxymoron?

Of course, there are situations where a variable need to be a â€˜normal.’ In fact, you might argue that most of the cases involve the need to modify a value. So unless you’re trying to write functional code (that likes immutability), you’ll end up with tons of examples when you need to change a value (or just part of an object).

Simple examples: calculating a sum of an array, iterators, small functions, changing health param in GameActor, setting a part of GPU pipeline.

Still, bear in mind that the most of the above examples could be rewritten into an â€˜immutable’ version as well. For example, you can use higher-order functions like Fold/Reduce, and recursion to implement many â€˜standard’ algorithms. But that’s going into functional languages area.

One remark: while I was writing this article I realized I make a distinction here: variables vs. larger objects. In theory, those are the same, but for practical reasons, it’s easier to use const on smaller, â€˜atomic’ types. So, I try to use const for smaller types: like numerics, strings, Vector2d, etc… but when I have some large custom class, I just skip const and allow to mutate its state (if needed). Maybe in my next iteration of my â€˜const correctness’ I’ll try to apply that rule also on larger objects… so this would be a more functional style of programming.

Summary

I hope after reading this post; you’ll at least try using const variables more often. It’s not about being 100% const every time, but it’s important to see benefits of such approach.

As I’ve described, the resulting code will be more verbose, explicit, cleaner (with probably smaller functions) and safer. Not to mention that you’ll get additional help from the compiler.

Do you const variables when possible?

Does your project guideline mention const correctness?

Like this article?

If want to read more from me, visit my blog at bfilipek.com. I write weekly about native/c++ programming stories.

C++17 In Details: Fixes and Deprecation

Bartlomiej Filipek — Wed, 28 Jun 2017 18:53:39 +0000

The new C++ Standard - C++17 - is near the end to be accepted and published. There's already a working draft, and not that long ago it went to the final ISO balloting. It's a good occasion to learn and understand what are the new features.

Let's start slowly, and today we'll look at language/library fixes and removed elements.

Note: This post was originally posted at my blog: Bartek's coding blog: C++17 in details: fixes and deprecation as part of the series about C++17 details.

Documents & Links

First of all, if you want to dig into the standard on your own, you can read the latest draft here:

N4659, 2017-03-21, Working Draft, Standard for Programming Language C++ - the link also appears on the isocpp.org.

Compiler support: C++ compiler support

In Visual Studio (since VS 2015 Update 3) you can try using Standard Version Switches and test your code conformance with the given standard: Standards version switches in the compiler.

Moreover, I've prepared a list of concise descriptions of all C++17 language features: grab it here. It's a one-page reference card, PDF.

There's even more: at the beginning of the year I've published long, collaborative article about most of C++17 features, have a look here. If you want to update it, add more examples, just do a pull request on the repo.

Removed things

The draft for the language contains now over 1586 pages! Due to compatibility requirements, the new features are added, but not much is removed. Fortunately, there are some things that could go away.

Removing trigraphs

Trigraphs are special character sequences that could be used when a system doesn't support 7-bit ASCII - like in ISO 646 character set . For example ??= generated #, ??- produces ~. BTW: All of C++'s basic source character set fits in 7-bit ASCII. The sequences are rarely used and by removing them the translation phase of the code might be simpler.

If you want to know more: c++03 - Purpose of Trigraph sequences in C++? - Stack Overflow, or Digraphs and trigraphs - Wikipedia.

More details in: N4086. If you really need trigraphs with Visual Studio, take a look at /Zc:trigraphs switch. Also, other compilers might leave the support in some way or the other. Other compiler status: done in GCC: 5.1 and Clang: 3.5.

Removing register keyword

The register keyword was deprecated in the 2011 C++ standard as it has no meaning. Now it's being removed. This keyword is reserved and might be repurposed in the future revisions (for example auto keyword was reused and now is something powerful).

More details: P0001R1, MSVC 2017: not yet. Done in GCC: 7.0 and Clang: 3.8.

Remove Deprecated operator++(bool)

This operator is deprecated for a very long time! In C++98 is was decided that it's better not to use it. But only in C++17, the committee agreed to remove it from the language.

More details: P0002R1, MSVC 2017: not yet. Done in GCC: 7.0 and Clang: 3.8.

Removing Deprecated Exception Specifications from C++17

In C++17 exception specification will be part of the type system (see P0012R1). Still the standard contains old and deprecated exception specification that appeared to be not practical and not used.

For example:

void fooThrowsInt(int a) throw(int) {  
   printf_s("can throw ints\n");  
   if (a == 0)  
      throw 1;  
}

The above code is deprecated since C++11. The only practical exception declaration is throw() that mean - this code won't throw anything. But since C++11 it's advised to use noexcept.

For example in clang 4.0 you'll get the following error:

error: ISO C++1z does not allow dynamic exception specifications [-Wdynamic-exception-spec]
note: use 'noexcept(false)' instead

More details: P0003R5, MSVC 2017: not yet. Done in GCC: 7.0 and Clang: 4.0.

Removing auto_ptr

This is one of my favorite update to the language!

In C++11 we got smart pointers: unique_ptr, shared_ptr and weak_ptr. Thanks to the move semantics the language could finally support proper unique resource transfers. auto_ptr was old and buggy thing in the language - see the full reasons here - why is auto_ptr deprecated. It should be almost automatically converted to unique_ptr. For some time auto_ptr was deprecated (since C++11). Many compilers would report this like:

warning: 'template<class> class std::auto_ptr' is deprecated

Now it goes into a zombie state, and basically, your code won't compile.

Here's the error from: MSVC 2017 when using /std:c++latest:

error C2039: 'auto_ptr': is not a member of 'std'

If you need help with the conversion from auto_ptr to unique_ptr you can check Clang Tidy, as it provides auto conversion: Clang Tidy: modernize-replace-auto-ptr.

More details: N4190

In the linked paper N4190: there are also other library items that were removed: unary_function/binary_function, ptr_fun(), and mem_fun()/mem_fun_ref(), bind1st()/bind2nd() and random_shuffle.

Fixes

We can argue what is a fix in a language standard and what is not. Below I've picked three things that sound to me like a fix for something that was missed in the previous standards.

New auto rules for direct-list-initialization

Since C++11 we got a strange problem where:

auto x { 1 };

Is deduced as initializer_list. With the new standard, we can fix this, so it will deduce int (as most people would initially guess).

To make this happen, we need to understand two ways of initialization: copy and direct.

auto x = foo(); // copy-initialization
auto x{foo}; // direct-initialization, initializes an
             // initializer_list (until C++17)
int x = foo(); // copy-initialization
int x{foo}; // direct-initialization

For the direct initialization, C++17 introduces new rules:

For a braced-init-list with only a single element, auto
deduction will deduce from that entry;
For a braced-init-list with more than one element, auto
deduction will be ill-formed.

For example:

auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
auto x2 = { 1, 2.0 }; // error: cannot deduce element type
auto x3{ 1, 2 }; // error: not a single element
auto x4 = { 3 }; // decltype(x4) is std::initializer_list<int>
auto x5{ 3 }; // decltype(x5) is int

More details in N3922 and also in Auto and braced-init-lists, by Ville Voutilainen. Already working since MSVC 14.0, GCC: 5.0, Clang: 3.8.

static_assert with no message

Self-explanatory. It allows just to have the condition without passing the message, the version with the message will also be available. It will be compatible with other asserts like BOOST_STATIC_ASSERT (that didn’t take any message from the start).

static_assert(std::is_arithmetic_v<T>, "T must be arithmetic");
static_assert(std::is_arithmetic_v<T>); // no message needed since C++17

More details: N3928, supported in MSVC 2017, GCC: 6.0 and Clang: 2.5.

Different begin and end types in range-based for

Since C++11 range-based for loop was defined internally as:

{
   auto && __range = for-range-initializer;
   for ( auto __begin = begin-expr,
              __end = end-expr;
              __begin != __end;
              ++__begin ) {
        for-range-declaration = *__begin;
        statement
   }
}

As you can see, __begin and __end have the same type. That might cause some troubles - for example when you have something like a sentinel that is of a different type.

In C++17 it's changed into:

{
  auto && __range = for-range-initializer;
  auto __begin = begin-expr;
  auto __end = end-expr;
  for ( ; __begin != __end; ++__begin ) {
    for-range-declaration = *__begin;
    statement
  }
}

Types of __begin and __end might be different; only the comparison operator is required. This little change allows Range TS users a better experience.

More details in P0184R0, supported in MSVC 2017, GCC: 6.0 and Clang: 3.6.

Summary

The language standard grows, but there's some movement in the committee to remove and clean some of the features. For compatibility reasons, we cannot delete all of the problems, but one by one we can get some improvements.

On my blog, I'm publishing more articles about C++17 details, so go there and stay tuned for more :)

Once again, remember to grab my C++17 Language Ref Card.

Like this article?

If want to read more from me, visit my blog at bfilipek.com. I write weekly about native/c++ programming stories.

DEV Community: Bartlomiej Filipek

Modern C++: Safety and Expressiveness with override and final

An Unexpected Code Path Errors

A Complex Case With #define

Risks - Sum Up

The Solution - Apply override

Guidelines

Adding final

Tools

Summary

Your Turn

More from the Author

C++20 Cheatsheet (with examples)

Want your own copy to print?

Language Features

Concepts

Modules

Designated Initializers

Range-based for with initializer

Attributes

consteval

Others

Library Features

std::format

Ranges

std::span

Others

Summary

2 Lines Of Code and 3 C++17 Features - The overload Pattern

Intro

New Features

Using Declarations

Custom Template Argument Deduction Rules

Extension to Aggregate Initialisation

Playground

Summary

Your Turn

References

More from the Author

11 Visual C++ Debugging Tips That Will Save Your Time

Helpers

1. Add LinePos to your debug output

2. Simple static variable to control the feature

3. Conditional breakpoints

4. Don’t step into unwanted functions

5. Add helper variables for your objects in debug mode

6. Write custom debugging visualizers

Techniques

7. Lots of objects to investigate?

8. Mouse events

9. Build debug visualizers, tools

Other

10. Debug the Release Build

11. Speed up debug builds!

Summary

More from the Author

Examples of Parallel Algorithms From C++17

Introduction

Execution Policies

New algorithms

MSVC Implementation

Examples

A Basic Example

Computing File Sizes

Counting Words in a String

Summary

Call to action

More from the Author

Simplify code with 'if constexpr' in C++17

Intro

Why compile time if?

std::enable_if

Use Case 1 - Comparing Numbers

Play with the code

Use case 2 - factory with variable arguments

Before C++17

With if constexpr

Play with the code

Wrap up

More from the Author

A Complex Case With `#define`

The Solution - Apply `override`

Adding `final`

`std::format`

`std::span`

`std::enable_if`

With `if constexpr`

Can `s_registered` be eliminated?