In my last C++ summary (for 2016) I wrote that the draft for C++17 is the most important thing that happened. I’ve put a list of features of the new standard, and today I’d like to expand the topic so we can learn some more details.

Intro

Work in Progress! I am happy to see your help with the list! :)

9 descriptions missing out of 39! Plus all from library changes

Updated: This post was updated at 8am, 13th January 2017.

If you have code examples, better explanations or any ideas, let me know! I am happy to update the current post so that it has some real value for others.

The plan is to have a list of features with some basic explanation, little example (if possible) and some additional resources, plus a note about availability in compilers. Probably, most of the features might require separate articles or even whole chapters in books, so the list here will be only a jump start.

See this github repo: github/fenbf/cpp17features. Add a pull request to update the content.

The list comes from the following resources:

• SO: What are the new features in C++17?
• cppreference.com/C++ compiler support.
• AnthonyCalandra/modern-cpp-features cheat sheet - unfortunately it doesn’t include all the features of C++17.
• plus other findings and mentions

And onf of the most important resource: Working Draft, Standard for Programming Language C++

Language Features

New auto rules for direct-list-initialization

N3922

Fixes some cases with auto type deduction. The full background can be found in Auto and braced-init-lists, by Ville Voutilainen.

It fixes the problem of deducing std::initializer_list like:

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

And for the direct initialization, new rules are:

• 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.

Basically, auto x { 1 }; will be now deduced as int, but before it was an initializer list.

static_assert with no message

N3928

Self-explanatory. It allows just to have the condition without passing the message, 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).

typename in a template template parameter

N4051

Allows you to use typename instead of class when declaring a template template parameter. Normal type parameters can use them interchangeably, but template template parameters were restricted to class, so this change unifies these forms somewhat.

template<template<typename...>typenameContainer>
//            used to be invalid ^^^^^^^^
struct foo;

foo<std::vector> my_foo;

Removing trigraphs

N4086

Removes ??=, ??(, ??>, …

Makes the implementation a bit simpler, see MSDN Trigraphs

Nested namespace definition

N4230

Allows to write:

namespace A::B::C {
//…
}

Rather than:

namespace A {
namespace B {
namespace C {
//…
}
}
}

Attributes for namespaces and enumerators

N4266

Permits attributes on enumerators and namespaces. More details in N4196.

enum E {
  foobar =0,
  foobat [[deprecated]]= foobar
};

E e = foobat;// Emits warning

namespace[[deprecated]] old_stuff{
void legacy();
}

old_stuff::legacy();// Emits warning

u8 character literals

N4267

UTF-8 character literal, e.g. u8'a'. Such literal has type char and the value equal to ISO 10646 code point value of c-char, provided that the code point value is representable with a single UTF-8 code unit. If c-char is not in Basic Latin or C0 Controls Unicode block, the program is ill-formed.

The compiler will report errors if character cannot fit inside u8 ASCII range.

Reference:

• cppreference.com/character literal
• SO: What is the point of the UTF-8 character literals proposed for C++17?

Allow constant evaluation for all non-type template arguments

N4268

todo…

Fold Expressions

N4295

More background here in P0036

Articles:

• C++ Truths: Folding Monadic Functions
• Simon Brand: Exploding tuples with fold expressions

Remove Deprecated Use of the register Keyword

P0001R1

The register keyword was deprecated in the 2011 C++ standard. C++17 tries to clear the standard, so the keyword is now removed.

Remove Deprecated operator++(bool)

P0002R1

The ++ operator for bool was deprecated in the original 1998 C++ standard, and it is past time to remove it formally.

Removing Deprecated Exception Specifications from C++17

P0003R5

Dynamic exception specifications were deprecated in C++11. This paper formally proposes removing the feature from C++17, while retaining the (still) deprecated throw() specification strictly as an alias for noexcept(true).

Make exception specifications part of the type system

P0012R1

Previously exception specifications for a function didn’t belong to the type of the function, but it will be part of it.

We’ll get an error in the case:

void(*p)()throw(int);
void(**pp)() noexcept =&p;// error: cannot convert to pointer to noexcept function

Aggregate initialization of classes with base classes

P0017R1

If a class was derived from some other type you couldn’t use aggregate initialization. But now the restriction is removed.

struct base {int a1, a2;};
struct derived : base {int b1;};

derived d1{{1,2},3};// full explicit initialization
derived d1{{},1};// the base is value initialized

To sum up: from the standard:

An aggregate is an array or a class with:
* no user-provided constructors (including those inherited from a base class),
* no private or protected non-static data members (Clause 11),
* no base classes (Clause 10) and // removed now!
* no virtual functions (10.3), and
* no virtual, private or protected base classes (10.1).

Lambda capture of *this

P0018R3

this pointer is implicitly captured by lambdas inside member functions. Member variables are always accessed by this pointer.

Example:

struct S {
int x ;
void f(){
// The following lambda captures are currently identical
auto a =[&](){ x =42;}// OK: transformed to (*this).x
auto b =[=](){ x =43;}// OK: transformed to (*this).x
      a();
      assert( x ==42);
      b();
      assert( x ==43);
}
};

Now you can use *this when declaring a lambda, for example auto b = [=, *this]() { x = 43 ; }. That way this is captured by value. Note that the form [&,this] is redundant but accepted for compatibility with ISO C++14.

Capturing by value might be especially important for async invocation, paraller processing.

Using attribute namespaces without repetition

P0028R4

Other name for this feature was “Using non-standard attributes” in P0028R3 and PDF: P0028R2 (rationale, examples).

Simplifies the case where you want to use multiple attributes, like:

void f(){
[[rpr::kernel, rpr::target(cpu,gpu)]]// repetition
do-task();
}

Proposed change:

void f(){
[[using rpr: kernel, target(cpu,gpu)]]
do-task();
}

That simplification might help when building tools that automatically translate annotated such code into a different programming models.

Dynamic memory allocation for over-aligned data

P0035R4

In the following example:

class alignas(16)float4{
float f[4];
};
float4*p =newfloat4[1000];

C++11/14 did not specify any mechanism by which over-aligned data can be dynamically allocated correctly (i.e. respecting the alignment of the data). In the example above, not only is an implementation of C++ not required to allocate properly-aligned memory for the array, for practical purposes it is very nearly required to do the allocation incorrectly.

C++17 fixes that hole by introducing additional memory allocation functions that use align parameter:

void*operatornew(std::size_t, std::align_val_t);
void*operatornew[](std::size_t, std::align_val_t);
voidoperatordelete(void*, std::align_val_t);
voidoperatordelete[](void*, std::align_val_t);
voidoperatordelete(void*, std::size_t, std::align_val_t);
voidoperatordelete[](void*, std::size_t, std::align_val_t);

Unary fold expressions and empty parameter packs

P0036R0

todo…

__has_include in preprocessor conditionals

P0061R1

This feature allows a C++ program to directly, reliably and portably determine whether or not a library header is available for inclusion.

Example: This demonstrates a way to use a library optional facility only if it is available.

#if __has_include(<optional>)
#  include <optional>
#  define have_optional 1
#elif __has_include(<experimental/optional>)
#  include <experimental/optional>
#  define have_optional 1
#  define experimental_optional 1
#else
#  define have_optional 0
#endif

Template argument deduction for class templates

P0091R3

Before C++17, template deduction worked for functions but not for classes.
For instance, the following code was legal:

void f(std::pair<int,char>);

f(std::make_pair(42,'z'));

because std::make_pair is a template function.
But the following wasn’t:

void f(std::pair<int,char>);

f(std::pair(42,'z'));

although it is semantically equivalent. This was not legal because std::pair is a template class, and template classes could not apply type deduction in their initialization.

So before C++17 one has to write out the types explicitly, even though this does not add any new information:

void f(std::pair<int,char>);

f(std::pair<int,char>(42,'z'));

This is fixed in C++17 where template class constructors can deduce type parameters. The syntax for constructing such template classes is therefore consistent with the syntax for constructing non-template classes.

todo: deduction guides.

• A 4 min episode of C++ Weekly on class template argument type deduction

• A 4 min episode of C++ Weekly on deduction guides

Non-type template parameters with auto type

P0127R2

todo…

Guaranteed copy elision

P0135R1

Articles:

• Jonas Devlieghere: Guaranteed Copy Elision

New specification for inheriting constructors (DR1941 et al)

P0136R1

todo…

Direct-list-initialization of enumerations

P0138R2

Allows to initialize enum class with a fixed underlying type:

enumclassHandle:uint32_t{Invalid=0};
Handle h {42};// OK

Allows to create ‘strong types’ that are easy to use…

Stricter expression evaluation order

P0145R3

todo…

constexpr lambda expressions

P0170R1

todo…

A 5 min episode of Jason Turner’s C++ Weekly about constexpr lambdas

Differing begin and end types in range-based for

P0184R0

Changing the definition of range based for from:

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

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.

[[fallthrough]] attribute

P0188R1

Indicates that a fallthrough in a switch statement is intentional and a warning should not be issued for it. More details in P0068R0.

switch(c){
case'a':
    f();// Warning emitted, fallthrough is perhaps a programmer error
case'b':
    g();
[[fallthrough]];// Warning suppressed, fallthrough is intentional
case'c':
    h();
}

[[nodiscard]] attribute

P0189R1

[[nodiscard]] is used to stress that the return value of a function is not to be discarded, on pain of a compiler warning. More details in P0068R0.

[[nodiscard]]int foo();
void bar(){
    foo();// Warning emitted, return value of a nodiscard function is discarded
}

This attribute can also be applied to types in order to mark all functions which return that type as [[nodiscard]]:

[[nodiscard]]structDoNotThrowMeAway{};
DoNotThrowMeAway i_promise();
void oops(){
    i_promise();// Warning emitted, return value of a nodiscard function is discarded
}

[A 4 min video about [[nodiscard]] in Jason Turner’s C++ Weekly](https://www.youtube.com/watch?v=l_5PF3GQLKc)

[[maybe_unused]] attribute

P0212R1

Suppresses compiler warnings about unused entities when they are declared with [[maybe_unused]]. More details in P0068R0.

staticvoid impl1(){...}// Compilers may warn about this
[[maybe_unused]]staticvoid impl2(){...}// Warning suppressed


void foo(){
int x =42;// Compilers may warn about this
[[maybe_unused]]int y =42;// Warning suppressed
}

[A 3 min video about [[maybe_unused]] in Jason Turner’s C++ Weekly](https://www.youtube.com/watch?v=WSPmNL9834U)

Ignore unknown attributes

P0283R2

Clarifies that implementations should ignore any attribute namespaces which they do not support, as this used to be unspecified. More details in P0283R1.

//compilers which don't support MyCompilerSpecificNamespace will ignore this attribute
[[MyCompilerSpecificNamespace::do_special_thing]]
void foo();

Pack expansions in using-declarations

P0195R2

Allows you to inject names with using-declarations from all types in a parameter pack.

In order to expose operator() from all base classes in a variadic template, we used to have to resort to recursion:

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

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

Now we can simply expand the parameter pack in the using-declaration:

template<typename...Ts>
structOverloader:Ts...{
usingTs::operator()...;
// […]
};

Remarks

• Implemented in GCC 7.0, see this change.

Decomposition declarations

P0217R3

Helps when using tuples as a return type. It will automatically create variables and tie them. More details in P0144R0. Was originally called “structured bindings”.

For example:

std::tie(a, b, c)= tuple;// a, b, c need to be declared first

Now we can write:

auto[ a, b, c ]= tuple;

Such expressions also work on structs, pairs, and arrays.

Articles:

• Steve Lorimer, C++17 Structured Bindings
• jrb-programming, Emulating C++17 Structured Bindings in C++14
• Simon Brand, Adding C++17 decomposition declaration support to your classes

Hexadecimal floating-point literals

P0245R1

Allows to express some special floating point values, for example, the smallest normal IEEE-754 single precision value is readily written as 0x1.0p-126.

init-statements for if and switch

P0305R1

New versions of the if and switch statements for C++: if (init; condition) and switch (init; condition).

This should simplify the code. For example, previously you had to write:

{
auto val =GetValue();
if(val)
// on success  
else
// on false... 
}

Look, that val has a separate scope, without it it will ‘leak’.

Now you can write:

if(auto val =GetValue(); val)
// on success  
else
// on false... 

val is visible only inside the if and else statements, so it doesn’t ‘leak’.

Inline variables

P0386R2

Previously only methods/functions could be specified as inline, now you can do the same with variables, inside a header file.

A variable declared inline has the same semantics as a function declared inline: it can be defined, identically, in multiple translation units, must be defined in every translation unit in which it is used, and the behavior of the program is as if there is exactly one variable.

structMyClass
{
staticconstint sValue;
};

inlineintconstMyClass::sValue =777;

Or even:

structMyClass
{
inlinestaticconstint sValue =777;
};

Articles

• SO: What is an inline variable and what is it useful for?

DR: Matching of template template-arguments excludes compatible templates

P0522R0

This feature resolves Core issue CWG 150.

From the paper:

This paper allows a template template-parameter to bind to a template argument whenever the template parameter is at least as specialized as the template argument. This implies that any template argument list that can legitimately be applied to the template template-parameter is also applicable to the argument template.

Example:

template<template<int>class>void FI();
template<template<auto>class>void FA();
template<auto>struct SA {/* ... */};
template<int>struct SI {/* ... */};
FI<SA>();// OK; error before this paper
FA<SI>();// error

template<template<typename>class>void FD();
template<typename,typename=int>struct SD {/* ... */};
FD<SD>();// OK; error before this paper (CWG 150)

(Some useful example needed, since it’s a bit vague to me).

std::uncaught_exceptions()

N4259

More background in the original paper: PDF: N4152 and GOTW issue 47: Uncaught Exceptions.

The function returns the number of uncaught exception objects in the current thread.

This might be useful when implementing proper Scope Guards that works also during stack unwinding.

A type that wants to know whether its destructor is being run to unwind this object can query uncaught_exceptions
in its constructor and store the result, then query uncaught_exceptions again in its destructor; if the result is different,
then this destructor is being invoked as part of stack unwinding due to a new exception that was thrown later than the object’s construction

The above quote comes from PDF: N4152.

constexpr if-statements

P0292R2

The static-if for C++! This allows you to discard branches of an if statement at compile-time based on a constant expression condition.

ifconstexpr(cond)
     statement1;// Discarded if cond is false
else
     statement2;// Discarded if cond is true

This removes a lot of the necessity for tag dispatching and SFINAE:

SFINAE

template<typename T, std::enable_if_t<std::is_arithmetic<T>{}>*=nullptr>
auto get_value(T t){/*...*/}

template<typename T, std::enable_if_t<!std::is_arithmetic<T>{}>*=nullptr>
auto get_value(T t){/*...*/}

Tag dispatching

template<typename T>
auto get_value(T t, std::true_type){/*...*/}

template<typename T>
auto get_value(T t, std::false_type){/*...*/}

template<typename T>
auto get_value(T t){
return get_value(t, std::is_arithmetic<T>{});
}

if constexpr

template<typename T>
auto get_value(T t){
ifconstexpr(std::is_arithmetic_v<T>){
//...
}
else{
//...
}
}

Articles:

• LoopPerfect Blog, C++17 vs C++14 - Round 1 - if-constexpr
• SO: constexpr if and static_assert
• Simon Brand: Simplifying templates and #ifdefs with if constexpr

Library Features

To get more details about library implementation I suggest those links:

• VS 2015 Update 2’s STL is C++17-so-far Feature Complete - Jan 2016
• libstdc++, C++ 201z status
• libc++ C++1z Status

This section only mentions some of the most important parts of library changes, it would be too impractical to go into details of every little change.

Merged: The Library Fundamentals 1 TS (most parts)

P0220R1

We get the following items:

• Tuples - Calling a function with a tuple of arguments
• Functional Objects - Searchers
• Optional objects
• Class any
• string_view
• Memory:
  
  • Shared-ownership pointers
  • Class memory_resource
  • Class memory_resource
  • Access to program-wide memory_resource objects
  • Pool resource classes
  • Class monotonic_buffer_resource
  • Alias templates using polymorphic memory resources
• Algorithms:
  
  • Search
  • Sampling

The wording from those components comes from Library Fundamentals V2 to ensure the wording includes the latest corrections.

Resources:

• Marco Arena, string_view odi et amo

Merged: The Parallelism TS, a.k.a. “Parallel STL.”,

P0024R2

Merged: File System TS,

P0218R1

Merged: The Mathematical Special Functions IS,

PDF - WG21 P0226R1

Improving std::pair and std::tuple

N4387

std::shared_mutex (untimed)

N4508

Variant

P0088R2

Splicing Maps and Sets

P0083R2

From Herb Sutter, Oulu trip report:

You will now be able to directly move internal nodes from one node-based container directly into another container of the same type. Why is that important? Because it guarantees no memory allocation overhead, no copying of keys or values, and even no exceptions if the container’s comparison function doesn’t throw.

Contributors

This is a place for you to be mentioned!

Contributors:

• Simon Brand
• Jonathan Boccara, Fluent{C++}

Summary

C++ is a surprising language. Sometimes simple things are not that simple in practice. Last time I argued that in function bodies const should be used most of the time. But two cases were missed: when moving and when returning a value.

Does const influence move and RVO?

Intro

Just to recall, we’re talking here about using const for variables inside function bodies. Not about const for a return type, const input parameters, or const methods. In example:

Z foo(T t, X x)
{
const Y y = superFunc(t, x);
const Z z = compute(y);
return z;
}

In the code above it’s best when y and z are declared as constant.

So what’s the problem then?

First of all, you cannot move from an object that is marked as const.

Another potential problem is when a compiler is trying to use (Named) Return Value Optimization (NRVO or RVO). Can it work when the variable to be elided is constant?

I got the following comment from u/sumo952:

Expert #1: “Put const on every variable that does not change. It’s good practice, prevents you from mistakes (changing a variable you intended to be const), and if you’re lucky, the compiler might be able to optimize better.”
Expert #2: “You cannot move from a variable marked as const, and instead the copy-constructor/assignment will be invoked more often. So spraying const-glitter all over your variables may do you more harm than good.”
Great! Now I got two contradictory expert opinions. And sorry, “Know what you’re doing” doesn’t help.

Let’s try to think about better advice. But first, we need to understand what’s the problem with move and RVO.

Move semantics

Move semantics (see this great post for more: C++ Rvalue References Explained
By Thomas Becker) enables us to implement a more efficient way of copying large objects. While value types need to be copied byte by byte anyway, types like containers, resource handles might sometimes be copied by stealing.

For instance, when you want to ‘move’ from one vector to another instead of copying all the data, you can just exchange pointers to the memory allocated on the heap.

Move operation cannot always be invoked, it’s done on r-value references - objects that are usually temporal, and it’s safe to steal from them.

Here’s some explicit code for move:

a = std::move(b);
// b is now in a valid, but 'empty' state!

In the simple code snippet above if the object a has a move assignment operator (or a move constructor depending on the situation), we can steal resources from b.

When b is marked as const instead of an r-value reference, we’ll get a const r-value’ reference. This type cannot be passed to move operators, so a standard copy constructor or assignment operator will be invoked. No performance gain!

Note, that there are const r-values in the language, but their use is rather exotic, see this post for more info if needed: What are const rvalue references good for? and also in CppCon 2014: Stephan Lavavej talk.

OK… but is this really a huge problem for us?

Temporary objects

First of all, most of the time move semantics works on temporary objects, so you won’t even see them. Even if you have some constant objects, the result of some function invocation (like a binary operator) might be something else, and usually not const.

const T a = foo();
const T b = bar();
const T c = a + b;// result is a temp object
// return type for the + operator is usually not marked as const
// BTW: such code is also a subject of RVO... read later...

So, in a typical situation, constness of the objects won’t affect move semantics.

Explicit moves

Another case is when you want to move something explicitly. In other words, you take your variable which is an l-value, and you want to make it as it was an r-value.

The core guideline mentions that we usually shouldn’t often call std::move explicitly:

ES.56:

ES.56: Write std::move() only when you need to explicitly move an object to another scope

And in the case when you really need such operation I assume you know what you’re doing! Using const here is not a good idea. So I agree that my advice can be altered a bit in that context.

Returning a value

In the case when copy elision cannot be applied the compiler will try to use a move assignment operator or a move constructor if possible. If those aren’t available, then we have to perform a standard copy.

For example:

MyTypeProduceType(int a)
{
MyType t;
    t.mVal = a;
return t;
}

MyTypeProduceTypeWithConst(int a)
{
constMyType t =ProduceType(a);
return t;
}

MyType t;
t =ProduceTypeWithConst(1);

What’s the expected output here? For sure two objects needs to be created t and one object inside the functions. But when returning from ProduceTypeWithConst the compiler will try to invoke move if possible.

MyType()
MyType()
operator=(MyType&& v)
~MyType()
~MyType()

As you can see marking the return object as const didn’t cause any problems to perform a move. It would be a problem only when the function returned a const MyType, but it returns MyType so we’re safe here.

So all in all, I don’t see a huge problem with move semantics.

Let’s now move to another topic RVO…

Return Value Optimization

RVO is an optimization performed by most compilers (and mandatory in C++17!). When possible, the compiler won’t create an additional copy for the temporal returned object.

MyTypeProduceType()
{
MyType rt;
// ...
return rt;
}

MyType t =ProduceType();// (N)RVO

The canonical C++ would do something like this in the code above:

• construct rt
• copy rt to a temporary object that will be returned
• copy that temporary object into t

But the compiler can elide those copies and just initialize t once.

You can read more about (N)RVO in the articles from FluentCpp and Undefined Behaviour.

Returning const

What happens if your object is const? Like:

MyTypeProduceTypeWithConst(int a)
{
constMyType t =ProduceType(a);
return t;
}

MyType t =ProduceTypeWithConst(1);

Can RVO be applied here? The answer is Yes.

It appears that const doesn’t do any harm here. What might be the problem is when RVO cannot be invoked, then the next choice is to use move semantics. But we already covered that in the section above.

The slightly altered advice

In function bodies:
Use const whenever possible. Exceptions:
* Assuming the type is movable, when you want to move explicitly such variable, then adding const might block move semantics.

Still, if you’re unsure and you’re working with some larger objects (that have move enabled), it’s best to measure measure measure.

Some more guidelines:

Core Guidelines, F.20:

The argument for adding const to a return value is that it prevents (very rare) accidental access to a temporary. The argument against is prevents (very frequent) use of move semantics.

Summary

While initially, I was concerned about some negative effects of using const in the case of move and RVO, I think it’s not that serious. Most of the time the compiler can elide copies and properly manage temporary objects.

You can play with the code here: @coliru.

• Did I miss something?
• In what situations you’re afraid to put const?

Have you seen my recent blog post with the list of C++17 features? Probably this is not the best measurement, but it got only ~30% of the average read (while other articles might get like 70, or even 90%). I am not complaining, the list is crazy and contains probably too many details of the new standard.

Another stat: C++ standard page count: from 879 pages for C++98/03 to 1586 for C++17 (draft)!

Do you need to learn all of that stuff to write good code?
How to stay sane in the C++ world today?

Intro

You probably know that C++ is a complex language. As I’ve found, there’s even a whole Wiki page about the criticism of Cpp. Modern C++ adds even more stuff to the package!

Here’s the full data about the page count in the specs that I’ve mentioned before:

• C++98/03 - 879, N1905, Oct 2005
• C++11 - 1324, last draft, N3337, Jan 2012
• C++14 - 1368, last draft, Nov 2014
• C++17 - 1586, draft, N4606

It looks like C++17 is almost ~80% ‘larger’ than C++98/03. You can complain about added complexity and that it’s hard to learn all of those things. But is this so terrible? What can you do about the whole situation?

This post was motivated by some stories recently found::

• HN: C++11 FAQ
• r/programming, lvalues and rvalues used to be simple things. Now, only a handful of people truly understand all facets of C++ value categories.
• HN: Why I don’t spend time with Modern C++ anymore | Hacker News
• r/programming, Modern C++ Features – decltype and std::declval

First, let’s see some problems that you might bump into in C++.

Some Problems

Just to name a few:

Too slow pace

In 2016, as I wrote in my summary post, we got the draft for C++17. While it’s great, that we get a new standard every three years, a lot of developers complained that the new standard is not what everyone waited for.

A lot of features: like concepts, modules, ranges, co-routines, … were not accepted and we need to wait at least three more years to get them in the spec.

So, for some features, the pace of standardization is very slow.

As a positive aspect, I can only say that most of the mentioned features are already implemented, at least in the experimental form. So you can play with them and be prepared for the final version. Take a look at GCC concepts, modules in VS or Clang, Ranges, etc.

Too fast pace

As usually, we might have two contradicting opinions here. Although for some people the pace is slow, for others it’s hard to keep up with the changes.

You’ve just learned C++11… and now you need to update the knowledge with C++14, and then C++17 is along the way. Three years is not that short time, but bear in mind the compiler conformance, company policies, team guidelines might walk at a different pace.

Do your companies update to the most modern C++ version immediately?

Confusion / Complexity

Just read that comment:

CallMeDonk

I love c++. It’s my go to language, but you have to admit its ‘hodge podge’ implementation of value types is bizarre at best. Most programmers including me prefer simple well-defined language constructs over bizarre and over complicated grammar. I’m not a computer language lawyer. I’m a programmer.

Is C++ clear in every part? Probably not…

Move semantics

The principle of move semantics are quite clear: instead of copying just try to exchange the pointers to allocated memory, and you should get a nice performance boost. But the devil is in the detail.

I don’t write a lot of generic code, so fortunately I don’t have to think about move semantics all the time. But I was quite confused when I bumped into move and const - see my last article on that. I don’t believe every C++ will understand the rules here. Especially that you now need to remember about 6 default operations generated by the compiler: default constructor, destructor, copy constructor, move constructor, assign operator and move assignment operator.

Rvalues/xvalues/prvalues… myValues, fooValues

The last ones are made up… but still having all of the value categories is overwhelming!

Previously you just had to know lvalue vs rvalue, now it’s a bit more subtle.

Still, the question is if you need to know it by hard on a daily basis?

Some good comments:

c0r3ntin

It is complicated, but not on a daily basis.
Can this value be addressed ? can it be copied ? can it be moved ? Should it be moved ?
There is very few situation where you want to actively to be very specific and need a full understanding. ( templated library writing, hot paths, etc).
Most of the time C++ is not more complicated than java or something. Sadly this is lost on most people. C++ may be the most complex language out there but you can write very good code without caring about the specific.
BigObject o = getBigObject();

Initialization

18 ways now! - Initialization in C++ is bonkers and the r/cpp thread

Template deduction

I was quite lost when I saw all the changes for C++17; there are so many details about templates deduction!

Although you might not write template code all the time (unless you’re a library developer), it’s good to remember that deduction rules now also apply on ‘auto’ type deduction since we have AAA (Almost Always Auto) rule.

Fortunately, the rules are getting a bit easier with C++17 where there are things like template <auto>, fixing auto i { 0 }, template template parameters, etc…

Others areas?

What are your main problems with the language?

So far, we’ve discussed some problems, so how to live with them… and possibly how to solve them?

How to stay sane

There’s no the perfect programming language, every one of them has some issues. Here are my suggestions how to cope with the problems of Modern C++.

Stay positive, the language is evolving

No one wants to write code using old tools. We’ve already seen a lot of complaints about old C++ before C++11. It took almost 13 years (counting from major C++98, not including minor C++03) to came up with the major version: C++11. Now we can be happy that we get back on track, and every three years there will be some changes. At the end of the day, you cannot say that your language is dead and old.

And the tools as well!

Thanks to Clang and also improved development speed in other platforms, we get tools like:

• Clang Tidy (previously clang- modernize)
• Clang Format
• Clang Static Analyzer
• VisualAssist
• Clion/Resharper C++
• VisualStudio - tools like C++ Core Checker
• PVS Studio
• …

While it’s not super great as for other languages (especially Java based or .NET based), it’s getting better and better. Bear in mind that because of the complex C++ grammar it’s very hard to implement tools that analyse the code on the fly.

Try to stay up to date

C++ community is very much alive. There are many blogs, books, conferences… and there’s even a chance a local community is in your city!

For a start, I just suggest going to isocpp.org the central place for all of the events/news/articles. Then you might check Meeting C++ and info about local C++ groups. There’s also reddit/cpp where constantly more and more good stuff is posted.

And remember about books like:

• The C++ Programming Language, 4th Edition 4th Edition
• Effective Modern C++
• Programming: Principles and Practice Using C++
• Discovering Modern C++: An Intensive Course for Scientists, Engineers, and Programmers

You can also take a look at my recent C++17 Lang Ref Card!

Too much details? Just don’t open the hood

One of the reasons C++ has so much power is that it allows you to implement code very close to the metal. You have control over all of the details, memory layout, performance optimizations, etc, etc… At the same time, such abilities increase the complexity of the language.

Still, if you don’t need to go that far, you can stay at a relatively higher level of abstraction.

Use what you need

C++ is a multi-paradigm language; you can use it many different ways. Recently, I’ve read an interesting comment that said that a Cpp programmer might for years do very well without touching advanced stuff like template metaprogramming or even exceptions. This heavily depends on the code style of the project.

Even such companies like Google limit features of C++, for example, they don’t use exceptions.

This is a bit of repetition, but if you’re not a library developer you might not get into troubles with custom move operators or move constructors. Similarly, advances metaprogramming stuff might also not be a crucial part of your code.

Incremental change

If you start from scratch or have a small code base then going to C++11/14 should be relatively easy. What about million-line of code, code that was started 20 years (or more!) ago?

Just do it step by step.

At least for the new code, you should start using Modern C++. Moreover, by applying “The Boy Scout Rule” you can improve surrounding code that you touch.

This will probably result in some mixed code, but still, it’s better than staying with the legacy style only.

Last resort: your old code will still compile!

One of the reason why C++ specs are getting larger and larger is that the language is backward compatible. So the committee usually introduces new features, but rarely remove the old stuff. So… your code can still compile. If you don’t want to move and use newer things then you can stay with your current style.

From time to time you’ll get some warnings about deprecated stuff or removed features (like auto_ptr in C++17), but even in that case, you can switch the compiler to target some older C++ standard.

Summary

This article is partially a rant, partially a ‘glorification.’ I try to see the bad sides of the language and its evolution process and some positive signs as well.

While we can complain about the complexity, pace of changes, etc… I think we cannot say that the language is dead. That’s a good thing.

I don’t think you have to rapidly chase the new features and immediately rewrite your existing code. Just try to stay up to date with news, use the features that really improves your work and gradually your code should improve and be more ‘modern’ (however, can that be defined - see meetingcpp article on that).

• What’s your approach when adopting new features from C++11/14/17/1z ?
• What’s your main problem with C++?
• Do you use modern C++ in your work?

One of the guidelines from Modern C++ is to avoid using raw new and delete. Instead, you should use a smart pointer, a container or other RAII object. Today I’d like to focus on so-called ‘sink functions’ that takes ownership of input parameters. How can we modernize code around such calls?

Intro

Briefly: a sink function is a function that takes ownership of an input pointer. Such function is now responsible for the allocated memory/resource. It can pass the ownership further or manage it on its own.

Here are links for more definitions: Cpp Wiki: Move Constructor,
Herb Sutter: spart pointer parameters, Simplify C++: Move Semantics

Here’s a little diagram:

As it’s shown on the picture: Foo() creates a resource - ptr - and passes it to Bar() then it’s transferred to DoStuff() that (hopefully) finalizes it and destroys.

In legacy code, you could probably see code similar to:

voidFoo()
{
MyType* pMyObject =newMyType();// << !

// change pMyObject somehow...

HandleMyType(pMyObject);// transfer ownership
}

// transfer ownership of pMyObject 
voidHandleMyType(MyType* pMyObject)
{
// handle the pointer...

delete pMyObject;// finalize...
}

Foo() - is a source type function.
HandleMyType() - is a sink type function.

To be more specific we’re talking here about parameters that are usually movable only and not copyable. Like pointers. If you pass a value type like int param then there’s no need to pass ownership.

Also, usually we’re talking about allocated memory, but it can be any kind of resource: like a file handle, network connection, DB connection, some unique state, etc.

The above code is as usually very simple. In a real example, the ownership can be passed multiple levels down in the call stack hierarchy. The pointer might be even stored in some object that lives much longer than the ‘creation’ point. We could invent lots of examples here. See the picture below that shows many layers where the resource might be processed and eventually released.

Ok… you’ve seen code like that, but is it safe and modern? Definitely not!

The problem

In the above code, you can clearly see a ‘contract’ between one function and another: who is the owner of the resource/pointer.

Can you violate this contract?

Yes… and it’s very simple!

You can easily forget to delete allocated memory, forget about the ownership.

While it’s relatively easy to spot such problem in a short example like the above, it might be a pain in real code! Probably you know what I mean here. There’s a high chance you’ve already tracked bugs/leaks like that :)

The problem is that the contract is almost “verbal” only, or “comment” only. The compiler cannot help you here.

So what if someone doesn’t free the memory?

What if the foo() method needs to exit early (because of some error)?

Modernize

To fix all of the above problems we need to use one powerful mechanism: RAII. Particularly in the form of unique_pointer.

Use unique_ptr

So how about the improved version:

voidFooU()
{
auto pMyObject = make_unique<MyType>();// <<

// change pMyObject somehow...

HandleMyTypeU(move(pMyObject));
}

voidHandleMyTypeU(unique_ptr<MyType> pMyObject)
{
// handle the pointer...
}

A bit better?

Can you violate the contract now?

It’s quite hard!

Do you get help from the compiler?

Yes! It will report compile time errors!

Can you leak the memory?

Not easily!

Is the code more expressive and clean?

Yes!

So many benefits by just using a simple pointer wrapper! Also from the performance point of view, you don’t lose anything, because unique_ptr is just a tiny wrapper around a raw pointer and has the same size as the raw pointer.

Since unique_ptr is a movable-only type (not copyable), you’ll get a compile-timer error if you just want to copy the pointer. That way you need to move the pointer explicitly and that way pass the ownership.

BTW: small improvement: there’s auto used in the example. That way we don’t need to write:

unique_ptr<MyType> pPtr = make_unique<MyType>();

And it follows “AAA” rule.

Partial solution

There’s also a partial solution to our original problem. Sometimes you cannot change the sink function - this might happen when you’re using some third party library. What you can do is at least to be safer at ‘your’ side of the code.

Basically, I would still create an unique_ptr, but since you cannot pass it to the old sink function, you need to release it and pass as a raw pointer.

voidFooUP()
{
auto pMyObject = std::make_unique<MyType>();// <<

// change pMyObject somehow...

if(condition)// the pointer will be deleted automatically here!
return;

HandleMyType(pMyObject.release());
}

As you see the code uses release() method to remove ownership from the pointer. It also returns the raw pointer so we can use it.

What you get here?

Possibly not that much, but at least when your function needs to return early (before passing the pointer), you can be sure the memory won’t leak.

Also, please bear in mind that in real code that ownership can be passed in multiple levels of call stack:

voidFoo()
{
// ...
FooInner(ptr);
}

voidFooInner()
{
// ...
FooX_Inner(ptr);
}

voidFooX_Inner()
{
// ...
FooLib_Inner(ptr);// cannot use unique_ptr here!
}

// ...

Let’s assume that FooLib_Inner cannot use unique_ptr. Still, I believe, there’s a sense in modernizing Foo and FooX_Inner. The code will be safer, and maybe at some point, you’ll be able to improve library code as well. Maybe the library will update, and it will support unique_ptr at some point.

Summary

Play with the code here: @coliru

This was a quick and straightforward post. I believe that by reducing a number of raw new and delete you can end up with much safer code. One way of doing this is to use unique_ptr when passing to sink type functions.

I hope it helps.

What are your strategies for limiting usage of new/delete?

I got very interested in one topic that recently appeared on on Andrzej’s Blog: Toggles in functions. I though that maybe is worth to express my opinion as a separate blog post.
Please take a look.

Intro

As Andrzej wrote in the article the whole point is how to improve the code around functions like:

RenderGlyphs(true,false,true,false);

We’d like not only to have more expressive code but to have safer code. 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?

Ideas

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

Small Enums

In theory we could write the following declarations:

enumclassUseCacheFlag{True,False};
enumclassDeferredFlag{True,False};
enumclassOptimizeFlag{True,False};
enumclassFinalRenderFlag{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?

structRenderGlyphsParam
{
bool useCache;
bool deferred;
bool optimize;
bool finalRender;
};
voidRenderGlyphs(Glyphs&glyphs,constRenderGlyphsParam&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.

Youo 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:

• Simplify C++: Use Stronger Types! -
• Type safe handles in C++ — I Like Big Bits
• Strong types for strong interfaces - Fluent C++
• foonathan::blog() - Type safe - Zero overhead utilities for more type safety
• Serialization - BOOST_STATIC_WARNING

One example

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

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

voidProcess(Container*pContainer,bool bWasReused);

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

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!

enumclassContainerCreateInfo{Err,Created,Reused};
ContainerCreateInfoCreateContainer(Container*pContainer);

voidProcess(Container*pContainer,ContainerCreateInfo createInfo);

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

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

By reading the original article from Andrzej and this additional few words from me I hope you get the idea about toggle type parameters. They 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 number of toggles/flags and have more expressive code?

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

There are probably billions of lines of code written in C++ already. New code is being written every day. But will this trend continue? Will you be able to find a C++ job in five years?
Let's have a quick view.

The Story

This post was motivated by a recent video from J. Sonmez, you can see it here: Does C++ Have a Future?

Briefly, John explained that although he loves/loved C++, he thinks that if you’re just starting you shouldn’t invest much in C++. It’s good to know C++ (since it gives you a lot of knowledge about underlying hardware, native code, etc.), but still, from a career point of view, there are better options at the moment.

To be clear, he also mentioned that if you’re a C++ guy already, there’s nothing to worry because there will be still jobs for you. Even in 50 years there might be some Cpp code laying around somewhere :)

My view

In my opinion, it’s not that bad with C++! Or at least I hope so :)

Where C++ is used?

First of all, let’s look where C++ is used. Just by looking at Bjarne Stroustrup’s page on C++ applications we can see that there are a lot of apps our there!

Adding my ideas, I could write that C++ is used almost everywhere:

• Computer games, game engines,
• Audio libraries,
• CAD/3D - like Autodesk, Maya, 3d studio max, Blender, etc
• Document editors (Adobe products, Xara, Office)
• Flight planning: Amadeus, Sabre
• large scale e-commerce at Amazon
• Google - various projects (search, Chromium browser, …)
• Operating systems: lots of languages usually used, but C++ and C are used for the core parts.
• Drivers
• Financial: Bloomberg for example, HPT (Hight Perf Trading) platforms
• Science: like Cern or NASA
• Compilers
• Programming tools: like
• Communication protocols, systems (like from Ericsson)
• Facebook
• HP (like Java core)
• Intel
• …
• plus a recent r/cpp discussion: Why use cpp other than performance?

Ok, we could list and list companies and products here for a long time.

Basically, from a low level system, drivers, to whole operating systems, game engines, games, high perf trading, scientific computation, flight planning, document editors…

As you can see C++ is not only in backed/perf code but also in UI - full system stack.

Also, in the mentioned systems, C++ might not be used as the only language. Sometimes it’s used in 99% of the code, in others maybe only 20%.

We also have to remember about legacy code that’s already there. Someone has to maintain it and add new features.

Any advantages?

What are the main benefits:

• Modern C++ - feels like a new language. Have a look at C++11/14/17 and the future - C++20 will bring even more great stuff.
• RAII - without garbage collector, you can clean your objects nicely!
• Performance and memory efficiency - you can optimize down to the hardware level.
  
  • BTW: I’ve seen a good about perf: “c++ does not give you performance, it gives you control over performance (Chandler Carruth)”
• Native, close to the metal, but still expressive and relatively clean. You can open the hood if you like, or stay and use higher level abstractions.
• Multi-paradigm - you’re not forced to use only OOP, you can mix different styles depending on the needs.
• Deterministic, well defined
• Templates
• Portability - there’s a C++ compiler probably for every platform!
• Integration - you can bind it with other languages, systems. For example easy to use with C#/Java for backend/perf code.
• Tools are getting better and better.
  • Especially thanks to many clang based tools!

And of course we have some little disadvantages, but let’s forget about them today :)

The language itself is growing, the community is amazing, new language standards appears regularly (you can take a look at my recent article: How To Stay Sane with Modern C++.

Also, by looking at the use of C++ and also it’s popularity (f.e. Tiobe’s 3rd place for a long time). Assuming you prefer system, “lower level” areas, I think that learning/starting with C++ is a good idea. Even if you go in other direction, the knowledge of C++ is universal and will give you a huge boost when learning other languages (like C#, Java, Go…).

Anything better that C++?

Can you find some better languages/platforms?

Yes. Especially if you want to build web applications it’s better to learn JavaScript or Ruby. Also, C# and Java are big players and should give you a lot of options and available jobs.

In the field of native languages we have D, Rust, Go… so it’s good to have an eye on them as well!

What to learn then?

Should you learn only C++ and nothing else (especially when you start)? Definitely NOT!

When you just start it’s better to have more choices. You should try several areas and after some time pick your favorite. You can learn C++ but also C# and see where it’s easier to create an UI (hmm… I wonder what’s the answer here :)). But at the same time, you can try Python or Java Script and compare the performance of some low-level code (if that’s possible in Python/JS…).

For some areas, C++ will be better. For some won’t. Moreover, it often happens that an application is built using several languages/technologies. So if you know, more you can help in more areas of the development.

But I am a C++ guru already!

Ok, but what if the job market shrinks? It’s not good to put all eggs in one basket, so I would also suggest learning something new from time to time.

It’s easier said than done, but learning something new - like a new lib, language, paradigm, etc… might have huge benefits on your existing code.

Job market?

Ok, let’s be practical now: What’s the job market for C++?
For example, in Cracow I have lots of options in Banking, Telecom, Flight planning, Gamedev, Enterprise Systems, Cars, Embedded… plus you can also find remote jobs like me :)

To be honest, I think it’s quite stable over the last seven years I think. Maybe it’s even growing a bit, since more tech companies have come to Cracow recently.

But let’s see what’s opinion from others:

What's the rough state of C++ job market in your area? Do we have more or less jobs for C++? #cplusplus#cpp#programming

— Bartlomiej Filipek (@fenbf) March 17, 2017

Clearly, it’s not that awesome, mostly stable, and you probably have more options for C# and Java, Java Script… however, it’s not decreasing super fast.

Summary

I am not saying that C++ is fantastic and you should abandon everything and just stick to it. If you’re just starting it’s good to have more options and learn different things. Even if you’re a C++ guy already, it’s vital to learn something new and improve.

Still, C++ jobs won't disappear overnight. C++ is a solid language and continues to be so. I expect the situation in job market to be stable with some possibility to slowly decrease over the years. But if you like this area you'll be able to find a C++ job anyway. I hope C++20 will add another good reason to stick with C++ and even move from other languages... but we need to wait a few years to see it happening.

Just in case you're learning about upcoming C++17, you can grab my one-page RefCard for the language features: link here.

• Let me know what's your opinion about the future of C++.
• Do you worry about the job market for this language?
• How does it look like in your area?
• What other languages are you learning now?

You want to transform one file into another, input into output. What API will you choose on Windows? WinApi? C++ Streams or good old stdio?

Last year in September I looked at four ways of processing a file on Windows. Also, I did some performance tests.
The whole project description was recently published in Visual Studio Magazine.

The idea was relatively straightforward: I’d like to transform data from one file and write that into another file. The transformation method wasn’t important (it could be just a copy or encryption). I was interested how can you achieve that using Apis: C++ streams, C stdio, WinApi basic and WinApi memory mapped files.

After I had built the whole processing code, I was able to test the performance. What API was the fastest? How do you think? What was the easiest to use?

The articles:

• 4 Ways To Transform a File on Windows with C++
• Transforming Windows Files on C++: What’s Fastest?

And there’s also GitHub repo with all sources: fenbf/WinFileTests

In the future it might be worth to try using multiple threads and see what are the benefits.

Please have a look at the articles and let me know what you think.

I have a great news! During the last meeting in Kona, the committee not only made final notes on the C++17 standard! There’s also a groundbreaking news that behind the curtains they planned C++18!

Intro

As it appears, the C++ Cometee finally understood that C++17 doesn’t contain the features everyone wanted. At the moment It’s impossible to change the standard - since it was already sent to the final ISO balloting… but during the last meeting in Kona (March), they decided to put all the efforts in the preparation of C++18!

C++18 will basically contain all the favourite features that programmers expected: So what we’ll get:

• Modules!
• Concepts
• Ranges
• Co-routines
• Contracts
• Possibly transactional memory

That’s really huge list of features!

In fact, most of the features are available in compilers already, as experimental features. So all we have to do during this year is to accept all the differences in the implementation, agree on the final scope, make the final wording… and wrap in the C++18 Standard.

Just to make it clear:

Modules

There are already two implementations that seems to work well: one from clang and one from Microsoft.

You can play with them here: Clang, Visual Studio .

Concepts

As we know, concepts (concepts-lite to be correct) are already available in GCC: link here.

A few days ago Gabriel Dos Reis announced - “Concepts are ready”!. See this PDF: P0606R0, Concepts Are Ready.

They are published as: ISO/IEC TS 19217:2015
Information technology – Programming languages – C++ Extensions for concepts.

Ranges

Containers Redesigned!

Already working implementation can be found on github, from Microsoft: link here. Works since Visual Studio 2015 update 3.

Co-routines

Co routines in Visual Studio: link here.

Contracts

Current proposal can be found here - P0542R0.

How to write preconditions and postconditions for functions.

Transactional memory

It’s already published as C++ extension: ISO/IEC TS 19841:2015
Technical Specification for C++ Extensions for Transactional Memory

So we just have to merge it into C++18.

Summary

I was really excited when I first heard that information! I’ve noticed that people complained that C++17 is not a major release and a lot of great features won’t be present. With C++18 we can fix this issue! Instead of waiting another three years (for C++20), we’ll get all the the best features in just one year from now.

• What do you think about C++18?
• Will the committee complete that on time?
• What features would you like to see in C++18?

As you’ve might already notice I’ve made a little joke on Saturday, which was the April Fools’ Day. I got the courage to announce C++18 next year! :)
While it was a bit funny, I didn’t expect much traffic (as it was Saturday). Still, my stats shows that a lot of people clicked and viewed the post. Thanks!

Today I’d like to continue the topic: why not and have C++18?

The story

Here are some of the comments:

NOPI: I know it’s a april fools joke but gosh I could wish that were actually true.

or

mps1729: Please, let this not be an April fool’s day post! I can dream, right?

and

sail0rm00n: i was really excited then i looked at the date :(

My fake news wasn’t that off the ground, as most of the features are very close to be accepted by the committee. Some of the features are already completed!

So, in fact, next year you can almost start using C++18: just take an experimental feature and play with it. Of course, you can start even now… no need to wait another year :)

The features

Let’s recall what the features of my C++18 was:

Modules

There are already two implementations that seem to work well: one from clang and one from Microsoft.

You can play with them here: Clang, Visual Studio .

• C++ Modules in VS 2015 Update 1 | Visual C++ Team Blog
• GoingNative 46: [Why you should be trying out] C++ Modules
• How do I use C++ modules in Clang? - Stack Overflow

Concepts

As we know, concepts (concepts-lite to be correct) are already available in GCC: link here.

A few days ago Gabriel Dos Reis announced - “Concepts are ready”!. See this PDF: P0606R0, Concepts Are Ready.

They are published as: ISO/IEC TS 19217:2015
Information technology – Programming languages – C++ Extensions for concepts.

Ranges

Already working implementation can be found on Github, from Microsoft: link here. Works since Visual Studio 2015 update 3.

Jonathan Boccara recently wrote an excellent introduction to Ranges, so you might want to have a look: Ranges: the STL to the Next Level - Fluent C++.

And also please follow one of the Ranges author: Eric Niebler.

Co-routines

Co routines in Visual Studio: link here.

James McNellis has a lot of talks about co-routines so check this out: CppCon 2016: “Introduction to C++ Coroutines”

Contracts

Current proposal can be found here - P0542R0.

How to write preconditions and postconditions for functions.

Transactional memory

It’s already published as C++ extension: ISO/IEC TS 19841:2015
Technical Specification for C++ Extensions for Transactional Memory

So we just have to merge it into C++18.

Transactional memory - cppreference.com
TransactionalMemory - GCC Wiki

Summary

Which one is your favourite? Let’s answer the quick survey:

While we can complain about the lack of the features in C++17 there’s also another option: since the features are almost done why not use them? I doubt your production code can be immediately upgraded to C++20 (when it’s out), the transition period is required. By experimenting you’ll get two things at least: you’ll learn something new, and the second point: you’ll understand if a given feature could work in your project.

Sometimes there’s a need to invoke a special action at the end of the scope: it could be a resource releasing code, flag set, code guard, begin/end function calls, etc. Recently, I’ve found a beautiful utility that helps in that cases.
Let’s meet gsl::final_act/finally.

Intro

Imagine we have the following code:

void addExtraNodes();
void removeExtraNodes();

boolScanner::scanNodes()
{
// code...
    addExtraNodes();

// code...
    removeExtraNodes();
returntrue;
}

We have a bunch of objects that scanNodes scans (global or shared container), but then we need to add some extra nodes to check. We want to preserve the initial container state, so at the end, we’re required to remove those additional nodes.

Of course, the design of the whole scan code could be much better so that we work on a copy of the container and adding or removing extra stuff would not be a problem. But there are places, especially in legacy code, where you work on some global container, and special care needs to be taken when changing it. A lot of bugs can happen when you modify a state, and someone expects a different state of the shared container.

My code seems to be working as expected… right? I call removeExtraNodes at the end of the function.

But what if there are multiple returns from scanNodes? It’s simple: we need to add multiple calls to removeExtraNodes. Ok….

What if there are some exceptions thrown? Then we also need to call our cleanup function before we throw…

So it appears we need to call removeExtraNodes not only before the last return!

Help needed

Let’s look at the C++ Core Guidelines. They suggest doing the following thing:

E.19: Use a final_action object to express cleanup if no suitable resource handle is available

The guideline says that we should strive for a better design, but still, it’s better than goto; exit approach, or doing nothing.

Ok… but what’s the solution here:

boolScanner::scanNodes()
{
// code...
    addExtraNodes();
auto _ = finally([]{ removeExtraNodes();});

// code...

returntrue;
}

What happened here?

All I did was to wrap the call to removeExtraNodes in a special object that will call a given callable object in its destructor. This is exactly what we need!

Where can we find that magical finally() code?

Just see Guideline Support Library/gsl_util.h.

Under the hood

The code is short, so I can even paste it here:

template<class F>
class final_act
{
public:
explicit final_act(F f) noexcept 
: f_(std::move(f)), invoke_(true){}

    final_act(final_act&& other) noexcept 
: f_(std::move(other.f_)),
       invoke_(other.invoke_)
{
        other.invoke_ =false;
}

    final_act(const final_act&)=delete;
    final_act&operator=(const final_act&)=delete;

~final_act() noexcept
{
if(invoke_) f_();
}

private:
    F f_;
bool invoke_;
};

Isn’t that beautiful?!

The above class takes a callable object - f_ - and then it will call it when it’s about to be destroyed. So even if your code returns early or throws an exception your cleanup code is required to be invoked.

To work nicely with move semantics, there has to be an additional boolean parameter invoke_. This will guarantee that we won’t call the code for temporary objects. See this commit for more information if needed:
Final_act copy/move semantics is wrong.

Additionally, to make our life easier, we have function helpers that create the objects:

template<class F>
inline final_act<F> finally(const F& f) noexcept
{
return final_act<F>(f);
}

template<class F>
inline final_act<F> finally(F&& f) noexcept
{
return final_act<F>(std::forward<F>(f));
}

So all in all, we can use finally() function in the client code. Maybe that could change in C++17 as we’ll get Template argument deduction for class templates.

What’s nice about this code?

• Clean, simple code
• Expressive, no comments needed
• Does one thing only
• It’s generic, so works on anything that’s callable
• Modern C++: so supports move semantics, noexcept,

Where could be used?

Just to be clear: don’t use finally approach too often! With the proper design, your objects shouldn’t work on a global state and take benefit from RAII as much as possible. Still, there are situations where finally is nice to use:

• begin/end functions - where you’re required to call end after something started. As in our example.
• flag setters. You have a shared flag, and you set it to a new state, but you have to reset it to the old state when you’re done.
• resources without RAII support. The guideline shows an example with malloc/free. If you cannot wrap it in an RAII object (for example by using smart pointers and custom deleters), final_act might work.
• safely closing the connection - as another example for resource clean-up in fact.

Do you see other places where final_act can help?

You can also look at this list: C++ List of ScopeGuard that appeared some time on Reddit (thread here)

Summary

final_act/finally is a beautiful and well-designed tool that can help with a dirty job of cleaning stuff. In your code, you should go for a better approach to clean things/resources, but if that’s not possible final_act is a great solution.

Do you use similar classes to clean things in your code?

Last time I wrote about final_act utility, and it seems I’ve opened a bit bigger box that I’ve previously assumed. Let’s continue with the topic and try to understand some of the problems that were mentioned in the comments.

Intro

Let’s remind what was the case last time:

I want to call a custom cleanup code at the end of the scope, and I want to be sure it’s invoked.

boolScanner::scanNodes()
{
// code...
    addExtraNodes();
auto _ = finally([]{ removeExtraNodes();});

// code...

returntrue;
}

I’ve used finally() from GSL that internally works on final_act object.

The most important thing!

OK, I know… I made a typo in the title of my original post! :)
I tried it several times, sent newsletter with the proper name… but the post was wrong :)

GSL -> Guideline Support Library, not GLS -> Guideline Library Support

Important use case

Last time I forgot to mention one huge case where all of those scope_exit/final_act stuff might be utilized.

I mean: transactions. That’s a general term for all of the actions that should be reverted when something fails. If you copied 95% of a file and got an error, you cannot leave such possibly corrupted file; you have to remove it and maybe start again. If you connected to a database and you want to write some records, you assume it’s atomic. I think this idea was ‘hidden’ somewhere in my examples, but it should be more exposed.

So whenever you’re dealing with code that has to be atomic, and transactional, such code constructs might be helpful. Sometimes you can wrap it in a RAII; often explicit code needs to be used.

No exceptions

First of all, my initial assumption was to use final_act in an environment where there are not many exceptions. For example, a lot of legacy code doesn’t use exceptions. Also Google C++ coding guideline doesn’t prefer exceptions (for practical reasons). This is a strong assumption, I know, maybe I did this automatically :)

Without exception handling around, we need to take care only of early returns. In that context, final_act works as expected.

With exceptions

OK… so what are the problems with exceptions then? final_act will work in most cases, so don’t just drop it whenever you have a code with exceptions… but we need to carefully look at some delicate parts here.

First thing: final act is noexcept

As explained many times through the comments in GSL repo (for example here), other issues

And from Final_act can lead to program termination if the final act throws an exception:

Final_act should be noexcept. It is conceptually just a handy way for the user to conjure up a destructor, and destructors should be noexcept. If something it invokes happens to throw, then the program will terminate.

In other words you should write the code that will be called with the same assumptions as other destructor code… so don’t throw anything there. That might be a little limitation when you want to call some ‘normal’ code, not just some clean-up stuff (on the other hand might that would be a bad design after-all?).

I’ve just notices a really great explanation why destructors shoudn’t throws:

from isocpp.org/faq

Write a message to a log-file. Terminate the process. Or call Aunt Tilda. But do not throw an exception!

Throwing from ctor or copy ctor

There’s a long-standing bug in the current implementation:

throwing copy and move constructors cause final_act to not execute the action · Issue #283 · Microsoft/GSL

How to workaround the bug?

We’re looking at this code:

explicit final_act(F f) noexcept 
: f_(std::move(f))
, invoke_(true)
{
}

final_act(final_act&& other) noexcept 
: f_(std::move(other.f_))
, invoke_(other.invoke_)
{
    other.invoke_ =false;
}

And especially those f_(std::move(other.f_)) calls.

The problem will occur if we raise an exception from the move/copy constructor. As I see this, it can happen only with custom move code that we have for the callable object. We should be safe when we use only lambdas as in:

auto _ = finally([] { removeExtraNodes(); });

Since lambdas (update: with no params) will have default code that won’t throw.

So maybe it’s not a major limitation?

update: I missed one thing. Take look at the example provided in the comment at r/cpp. An exception can also be thrown from a copy/move constructor from some argument of the lambda object (since lambdas are 'internally' represented as functor objects and their params are members of that functor). Still, this is probably a quite rare case.

Still, if you plan to use some advanced/custom callable functors, with special move code then it might be good to take something different than final_act.

Other solutions

To be honest, I also assumed that since final_act is proposed in Core Guidelines, then it’s the best choice that we have in Modern C++! But apparently we have some other possibilities:

The talk

First of all please watch this:

CppCon 2015: Andrei Alexandrescu “Declarative Control Flow”

The paper

And read that:

PDF, P0052R3 - Generic Scope Guard and RAII Wrapper for the Standard Library

Roughly, the plan is to have (C++20?) a set of tools:

• std::scope_exit
• std::scope_success
• std::scope_fail

scope_exit is meant to be a general-purpose scope guard that calls its exit function when a scope is exited. The class templates scope_fail and scope_success share the scope_exit’s interface, only the situation when the exit function is called differs. These latter two class templates memorize the value of uncaught_exceptions() on construction and in the case of scope_fail call the exit function on destruction, then uncaught_exceptions() at that time returns a greater value, in the case of scope_success when uncaught_exceptions() on destruction returns the same or a lesser value.

this assumes uncaught_exceptions() returns int not just bool.

folly/ScopeGuard.h

There’s already working code

folly/ScopeGuard.h - master

D Language

In D we have built-in support for such structures:

scope(exit) removeExtraNodes();

see here for some examples Dlang: Exception Safety

Copy elision

The existing code works now and doesn’t rely on Guaranteed Copy Elision that we’ll have in C++17. In order to support this they have to introduce that special bool parameter.

See discussion in Final_act copy/move semantics is wrong

Summary

As it appears final_act is a simple utility that should work well in case where your exit code doesn’t throw exceptions (and also doesn’t throw from copy/move constructors!). Still, if you need some more advanced solutions you might want to wait for general std::scope_exit/_success/_fail utilities.

One of the most important use case is whenever we need transactional approach with some actions. When we require to call some clean-up code after it succeeded or failed.

Meta-blogging-opinion: The beauty of blogging is that often you write about one topic and you unravel (for yourself) a whole new areas. That way blogging is a great way of learning things!

BTW: as a homework you can write a macro FINALLY that wraps the creation of the auto variable and makes sure we have a different name for that variable - so that you might have several final blocks in a function/scope.

Imagine you have an array of booleans (or an array of ‘conditions’), and you want to pack it - so you use only one bit per boolean. How to do it? Let’s do some experiments!

Motivation

I started writing this post because I came across a similar problem during my work some time ago. The code in one area of our system packed boolean results of a condition into bits. I wondered if I could optimize that process. This ‘algorithm’ is not a rocket science, but as usually, it opened a whole box of details and interesting solutions. So I decided to share it with my readers.

To illustrate the problem, we might think about an image in greyscale. We want to generate another image that has only two colors: white or black; we use a threshold value to distinguish between white and black color from the input image.

outputColor[x][y] = inputColor[x][y] > Threshold;

The input has some integer range (like 0…255), but the output is boolean: true/false.

Like here, image thresholding:

Then we want to pack those boolean values into bits so that we save a lot of memory. If bool is implemented as 8bit unsigned char, then we can save 7/8 of memory!

For example, instead of using 128kb for 256x512 greyscale image, we can now use 16kb only.

256 X 512 = 131072 (bytes) = 128kb
131072/8 = 16384 (bytes) = 16kb

Should be simple to code… right?

The algorithm

To make things clear let’s make some initial assumptions:

• input:
  
  • array of integer values
  • length of the array: N
  • threshold value
• output:
  
  • array of BYTES of the length M
  • M - number of bytes needed to write N bits
  • i-th bit of the array is set when inputArray[i] > threshold.

Brief pseudo code

for i = 0...N-1
    byte = pack (input[i] > threshold, 
                 input[i+1] > threshold, 
                 ..., 
                 input[i+7] > threshold)
    output[i/8] = byte
    i+=8

// handle case where N not divisible by 8

Alternatively, we might remove the threshold value and just take input array of booleans (so there won’t be any need to make comparisons).

Drawbacks of packing

Please note that I only focused on the ‘packing’ part. With the packed format you save memory, but there are more instructions to unpack a value. Sometimes this additional processing might cause the slow-down of the whole process! Always measure measure measure because each case might be different!

This problem is similar to compression algorithms, although packing is usually much faster process. As always, there’s a conflict between the storage and the computation power (Space–time tradeoff).

The benchmark

I want to compare several implementations:

• std::bitset
• std::vector of bools
• one ‘manual’ version
• second ‘manual’ version

Plus, the next time we’ll also add parallel options…

For the benchmarking library, I decided to use Celero. You can find more details about using it in my post about Benchmarking Libs for C++.

With Celero there’s an easy way to express different options for the benchmark. So for example, I’d like to run my code against different sizes of the input array: like 100k, 200k, … Also, there’s a clean way to provide setUp/tearDown methods that will be invoked before each run.

The base fixture provides input array:

inputValues.reset(newint[N]);
referenceValues.reset(newbool[N]);
arrayLength = N;

//Standard mersenne_twister_engine seeded with 0, constant
std::mt19937 gen(0);
std::uniform_int_distribution<> dist(0,255);

// set every byte
for(int64_t i =0; i < experimentValue;++i)
{
    inputValues[i]= dist(gen);
    referenceValues[i]= inputValues[i]>ThresholdValue;
}

std::bitset<N>

OK, this version will be really simple, take a look:

for(int64_t i =0; i < arrayLength;++i)
    outputBitset.set(i, inputValues[i]>ThresholdValue);

The only drawback of using bitset is that it requires compile time N constant. Also, bitset is implementation specific, so we’re not sure how the memory is laid out internally. I would reject this version from the final production code, but it’s useful as a baseline.

For example, here’s the fixture for this baseline benchmark:

classStdBitsetFixture:publicCompressBoolsFixture
{
public:
virtualvoid tearDown()
{
for(int64_t i =0; i < arrayLength;++i)
Checker(outputBitset[i], referenceValues[i], i);
}

    std::bitset<MAX_ARRAY_LEN> outputBitset;
};

In tearDown we check our generated values with the reference - Checker just checks the values and prints if something is not equal.

std::vector<bool>

Another simple code. But this time vector is more useful, as it’s dynamic and the code is still super simple.

for(int64_t i =0; i < arrayLength;++i)
    outputVector[i]= inputValues[i]>ThresholdValue;

And the fixture:

classStdVectorFixture:publicCompressBoolsFixture
{
public:
virtualvoid setUp(int64_t experimentValue) override
{
CompressBoolsFixture::setUp(experimentValue);

        outputVector.resize(experimentValue);
}

virtualvoid tearDown()
{
for(int64_t i =0; i < arrayLength;++i)
Checker(outputVector[i], referenceValues[i], i);
}

    std::vector<bool> outputVector;
};

This time, we generate the vector dynamically using experimentValue (N - the size of the array).

Still, vector<bool> might not be a good choice for the production code; see 17.1.1 Do not use std::vector | High Integrity C++ Coding Standard.

Manual version

The first two versions were just to start with something, let’s now create some ‘real’ manual code :)

I mean ‘manual’ since all the memory management will be done but that code. Also, there won’t be any abstraction layer to set/get bits.

The setup looks like this:

virtualvoid setUp(int64_t experimentValue) override
{
CompressBoolsFixture::setUp(experimentValue);
    numBytes =(experimentValue +7)/8;
    numFullBytes =(experimentValue)/8;
    outputValues.reset(newuint8_t[numBytes]);
}

outputValue is just a unique_ptr to array of uint8_t. We have N/8 full bytes and also there’s one at the end that might be partially filled.

The first case will use just one variable to build the byte. When this byte is complete (8 bits are stored), we can save it in the output array:

uint8_tOutByte=0;
int shiftCounter =0;

auto pInputData = inputValues.get();
auto pOutputByte = outputValues.get();

for(int64_t i =0; i < arrayLength;++i)
{
if(*pInputData >ThresholdValue)
OutByte|=(1<< shiftCounter);

    pInputData++;
    shiftCounter++;

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

// our byte might be incomplete, so we need to handle this:
if(arrayLength &7)
*pOutputByte++=OutByte;

Improvement

The first manual version has a little drawback. As you see, there’s only one value used when doing all the computation. This is quite inefficient as there’s little use of instruction pipelining.

So I came up with the following idea:

uint8_tBits[8]={0};
constint64_t lenDivBy8 =(arrayLength /8)*8;

auto pInputData = inputValues.get();
auto pOutputByte = outputValues.get();

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

*pOutputByte++=Bits[0]|Bits[1]|Bits[2]|Bits[3]|
Bits[4]|Bits[5]|Bits[6]|Bits[7];
    pInputData +=8;
}
if(arrayLength &7)
{
autoRestW= arrayLength &7;
    memset(Bits,0,8);
for(longlong i =0; i <RestW;++i)
{
Bits[i]=*pInputData ==ThresholdValue?1<< i :0;
        pInputData++;
}
*pOutputByte++=Bits[0]|Bits[1]|Bits[2]|Bits[3]|Bits[4]|Bits[5]|Bits[6]|Bits[7];
}

What happened here?

Instead of working on one variable I used eight different variables where we store the result of the condition. However, there’s still a problem when doing that large OR. For now, I don’t know how to improve it. Maybe you know some tricks? (without using SIMD instructions…)

Results

Was I right with this approach of using more variables? Let’s see some evidence!

Intel i7 4720HQ, 12GB Ram, 512 SSD, Windows 10.

The optimized version (using separate variables) is roughly 5x faster that bitset and almost 3.5x faster than the first manual version!

The chart:

Summary

The experiment was not so hard… so far! It was a good exercise for writing benchmarks.

What can we see from the results? The first manual version was still better than the std::bitset, but worse than std::vector. Without looking at the traces, profiles I optimized it by using more variables to compute the conditions. That way there was less data dependency and CPU could perform better.

Next time I’ll try to parallelize the code. How about using more threads or vector instructions? For example, I’ve found a really interesting instruction called: _mm_movemask_epi8… See you next week.

code on github: fenbf/celeroTest/celeroCompressBools.cpp

Let’s continue with the topic of packing boolean arrays into bits. Last time I’ve shown a basic - single threaded version of this ‘super’ advanced algorithm. By using more independent variables, we could speed things up and go even faster than no packing version! We’ve also used std::vector and std::bitset. Today I’d like to look at making the task parallel.

Read the first part here: Packing Bools, Performance tests

Recall

Just to recall, there’s an array of values and a threshold value. We want to test input values against that Threshold and store boolean condition results into bits.

Brief pseudo code

for i = 0...N-1
    byte = pack (input[i] > threshold, 
                 input[i+1] > threshold, 
                 ..., 
                 input[i+7] > threshold)
    output[i/8] = byte
    i+=8

// handle case where N not divisible by 8

In other words, we want to pack boolean results:

true, false, true, false, true, false, true, true

into full byte

11010101

where the first value corresponds to the first bit of the byte.

Simd, SSE2

The improved version of the solution uses eight separate values to store the result of the comparison and then it’s packed into one byte. But with SIMD we could do even more. There’s a way to pack 16 values at once using only SSE2 instructions. Can this be faster?

The core part of this approach is to use _mm_movemask_epi8. As we can read here:

int _mm_movemask_epi8 (__m128i a)

Create mask from the most significant bit of each 8-bit element in a,
and store the result in dst.

Since the comparison instructions set value 0xFF or 0, the above code is perfect to do the packing.

So the code can look like this:

auto in16Values = _mm_set_epi8(/*load 16 values*/);
auto cmpRes = _mm_cmpgt_epi8(in16Values, sseThresholds);
// cmpRes will stores 0xFF or 0 per each comparison result
auto packed = _mm_movemask_epi8(cmpRes);
*((uint16_t*)pOutputByte)=static_cast<uint16_t>(packed);

packed will be 16 bit mask composed from most significant bit of each 8-bit element in cmpRes. So this is exactly what we need.

The problem

Unfortunately, there’s a little problem. _mm_cmpgt_epi8 compares only signed byte values, so we need to do more work to support unsigned version.

There wouldn’t be any problem if we compared with the equality operator, but for greater than it’s not an option.

You can read more about missing SSE instruction in this article: A few missing SSE intrinsics BTW: Thanks @malcompl for letting me know on Twitter.

Implementation

Maybe it will be unfair, but to solve the signed/unsigned problem I just make a conversion code that subtracts 128 from the input values (and the threshold). So that conversion is not counted in the measurement.
In the end, you’ll see the reason for doing this.

Auto vectorization

What about auto-vectorization? Maybe I am a terrible programmer, but it seems that most of my loops are hard to make vectorized. You can try and enable auto-vectorization in Visual Studio. But every time I do this I get almost zero success and no vectorized loops. See MSDN Auto-Parallelization and Auto-Vectorization. Maybe it’s better in GCC/Clang?

Threading with OpenMP

So far the code was single-threaded. We should be leveraging all available cores on our machines. Even in typical user devices, there are two or more cores (sometimes plus hyper-threading).

I don’t want to create a sophisticated task-queue worker system, so I got one idea: what about OpenMP? Our problem is quite simple, and what’s most important: we can perform packing in a highly parallel manner, as there are almost no conflicts between packed bytes.

Visual Studio offers a simple switch that enables OpenMP 2.0. As far as I can see GCC offers almost the newest version (4.5), and Clang allows to use OpenMP 3.1.

BTW: why VS only offers OpenMP 2.0… why we cannot go higher? Other people complained, see this thread: Add support for OpenMP 4.5 to VC++ – Visual Studio

If you want to have a quick intro about OpenMP, I suggest this resource: Guide into OpenMP: Easy multithreading programming for C++.

Basically, OpenMP offers a fork-join model of computation:

The picture comes from wikipedia.

Our problem is perfect for such scenario. Theoretically, we could spread one thread per byte! So each byte packing would get its own thread. OK, maybe it’s not the best option as the overhead of thread switching would be much heavier than the computation itself, but I hope you get what I meant here.

What’s great about OpenMP is that it will handle all the hard part of threads management. All we have to do is to mark the parallel region and rewrite code in a way it’s easy to be run on separate threads.

So our version with OpenMP uses the following code

#pragma omp parallel forprivate(Bits)
for(int i =0; i < numFullBytes;++i)
{
auto pInputData = inputValues.get()+ i*8;
Bits[0]= pInput[0]>Threshold?0x01:0;
Bits[1]= pInput[1]>Threshold?0x02:0;
Bits[2]= pInput[2]>Threshold?0x04:0;
Bits[3]= pInput[3]>Threshold?0x08:0;
Bits[4]= pInput[4]>Threshold?0x10:0;
Bits[5]= pInput[5]>Threshold?0x20:0;
Bits[6]= pInput[6]>Threshold?0x40:0;
Bits[7]= pInput[7]>Threshold?0x80:0;

    outputValues.get()[i]=Bits[0]|Bits[1]|Bits[2]|Bits[3]|
Bits[4]|Bits[5]|Bits[6]|Bits[7];
}
// and then the part for handling the last not full byte...

All I had to do was to reorganize code a bit - starting from my not-depended version. Now each loop iteration works on one byte and 8 input values. We have a private section - Bits, that will be separate for each thread.

OpenMP will try to spread the work across available worker threads. Usually, it will be the number of cores. For example my machine has 4 cores with HT, so OpenMP reports 8 in my case (using omp_get_max_threads()).

Not bad as just one line of code?

OK, so I have probably 8 worker threads available… will my initial code perform 8x faster? Probably not, as we need to count additional API/Library overhead. But 2x or even more might easily happen.

Packed struct

David Mott made a comment, where he suggested using packed structs.

Why should we manually perform bit operations? Maybe we can force the compiler and get some help? Why not :)

struct bool8 
{
uint8_t val0 :1;
uint8_t val1 :1;
uint8_t val2 :1;
uint8_t val3 :1;
uint8_t val4 :1;
uint8_t val5 :1;
uint8_t val6 :1;
uint8_t val7 :1;
};

the processing code is much cleaner now:

for(int64_t j =0; j < lenDivBy8; j +=8)
{
    out.val0 = pInputData[0]>ThresholdValue;
    out.val1 = pInputData[1]>ThresholdValue;
    out.val2 = pInputData[2]>ThresholdValue;
    out.val3 = pInputData[3]>ThresholdValue;
    out.val4 = pInputData[4]>ThresholdValue;
    out.val5 = pInputData[5]>ThresholdValue;
    out.val6 = pInputData[6]>ThresholdValue;
    out.val7 = pInputData[7]>ThresholdValue;

*pOutputByte++= out;
    pInputData +=8;
}

The OR operation is completely hidden now (maybe even not needed as the compiler can do its magic).

The case for the last byte is not as clean, but also not that bad:

if(arrayLength &7)
{
autoRestW= arrayLength &7;
    out ={0,0,0,0,0,0,0,0};
if(RestW>6) out.val6 = pInput[6]>Threshold;
if(RestW>5) out.val5 = pInput[5]>Threshold;
if(RestW>4) out.val4 = pInput[4]>Threshold;
if(RestW>3) out.val3 = pInput[3]>Threshold;
if(RestW>2) out.val2 = pInput[2]>Threshold;
if(RestW>1) out.val1 = pInput[1]>Threshold;
if(RestW>0) out.val0 = pInput[0]>Threshold;
*pOutputByte++= out;
}

We could also use union to provide array access for bits.

Results

Ok, here’s the final run, with all versions:

And the chart for all:

Chart for versions performing better than no packing

• OpenMP is a great way to make things faster, we get around 2.5…3x better performance (although I have 8 available system threads…)
• Using packed structs is a really good option: the bit playing code is hidden and the compiler is responsible to pack things. And it performs almost the same as manual version. Even faster for larger sets of data.
• My simd version wasn’t perfect, but I was still hoping for more gains. It operates on 16 input values at once (as opposed to 8 values in other versions). But the perf was slower. I am not an expert of simd stuff, so maybe there’s a way to improve?

Other solutions

• Recently Daniel Lemire has posted a list: Compressed bitset libraries in C and C++.
• OpenCL - we could go fully parallel and use a GPU approach. The problem is quite simple so I didn’t consider going into OpenCL implementation, but in the production code, if the algorithm was essential to the whole system… then why not.
• I need to see that talk mentioned in the comments: CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures” - YouTube. As it covers some pretty crazy structures that also might help with bit packing… Or maybe you know how to apply such ideas onto my code?

Summary

Ufff… all done :)

What could we learn from the benchmarks?

• We can save some space by going into bit mode and at the same time the performance of packing might be faster than ‘no packing’ version.
• The Standard Library containers like vector of bools or bitset doesn’t perform well, it’s better to create manual versions, adjusted to a particular need.
• Using compiler to to the hard work: in our case it’s bit setting is quite a good alternative.
• If the task is highly parallel make sure you use all options to make things faster: reduce dependency of variables (also temp vars), use simd if possible, or threading libraries.
• As always measure measure measure as your case might be different.

I hope you enjoyed those tests. The problem was simple, but there are many ways we can explore the topic. And that’s only the tip of an iceberg when it comes to packing/compressing bitmaps.

Code on github: fenbf/celeroTest/celeroCompressBools.cpp

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 other version.

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

staticconstintThresholdValue= 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