Category Archive for C++

C++17: std::scoped_lock

C++17 includes an std::scoped_lock (defined in <mutex>) which basically replaces std::lock_guard. Both are RAII classes that automatically unlock a mutex when they are destroyed. The only difference between the two is that the new scoped_lock can handle multiple mutexes automatically, while lock_guard is limited to a single mutex.

Using the scoped_lock RAII class is straightforward. Here is an example:

std::mutex mutex1;
// ...
std::scoped_lock<std::mutex> sl(mutex1);

The scoped_lock class template is a variadic template supporting any number of mutexes:

std::mutex mutex1;
std::recursive_mutex mutex2;
// ...
std::scoped_lock<std::mutex, std::recursive_mutex> sl(mutex1, mutex2);

The declaration of the scoped_lock can be simplified thanks to C++17 template argument deduction for constructors:

std::mutex mutex1;
std::recursive_mutex mutex2;
// ...
std::scoped_lock sl(mutex1, mutex2);


Share

C++17: Template Argument Deduction for Constructors

C++ always had support for template argument deduction when calling function templates. For example, suppose you have the following function template:

template<typename T>
void MyFunction(const T& data) { /* ... */}

It’s a function template with one template parameter. When you call this function, you do not have to specify the type of the template parameter explicitly. C++ automatically deduces the type T based on the arguments passed to the function. For example:

MyFunction(5);
MyFunction("Test");

If you really want to specify the template type explicitly you do this as follows:

MyFunction<int>(5);
MyFunction<std::string>("Test");

Up to C++17, this deduction only worked for function templates. C++17 adds support for template argument deduction for constructors of class templates.

For example, before template argument deduction for constructors, when you instantiate any Standard Library container you have to specify the type of the elements you want to store in the container:

std::vector<int> ints = { 11,22,33 };

With C++17’s template argument deduction for constructors, you can omit the explicit specification of the type. Of course, this only works when you instantiate the container and immediately initialize it with initial elements, otherwise the compiler has no data from which it can deduce any types. So, the above example can be written in C++17 as follows:

std::vector ints = { 11,22,33 };

This seemingly little feature has quite an impact. Because of the lack of this feature in previous versions of C++, the Standard Library included helper function templates. For example, a std::pair<int, std::string> can be constructed in the following two ways (pre-C++17):

std::pair<int, std::string> myPair1{ 11, "Eleven" };
auto myPair2 = std::make_pair(12, "Twelve");

Either you directly use the std::pair class and explicitly specify the template parameters, or, you use the specially-introduced std::make_pair() function template that can do the template argument deduction.

With C++17’s new deduction rules, you can forget about the helper function templates, and simply write the following:

std::pair myPair3{ 13, "Thirteen" };

Similarly for other helper function templates that were introduced earlier like std::make_move_iterator() to make a std::move_iterator(), and so on.

If you want to add support for template argument deduction to your own classes, then you will have to write your own so-called deduction guides, but that’s for a future post.

Share

Next BeCPP UG Meeting Planned For February 4th, 2019

The next meeting of the Belgian C++ Users Group is planned for Monday February 4th, 2019 at 18:00 at Sioux @ Aldhem Hotel (Room d’Artagnan 3 & 4).

Sioux ( http://www.sioux.eu/ ) is sponsoring this event by providing the location, drinks and catering.

Sioux Logo

The agenda is as follows:

  • 18:00: Sandwiches.
  • 18:30: Session 1: Parsing CSS in C++ with Boost Spirit X3 (Ruben Van Boxem)
    Reading and writing is a fundamental part of programming. Even more so in C++, as it is a relatively low-level language. If not hand-written from scratch, C++ programmers often resort to parser generators such as Antlr, Bison, byacc, Flex, and many others. The former option increases maintenance burden, as the code involved is usually not trivial and error-prone. The latter option complicates the build setup and one loses a certain degree of flexibility in how the parser can be handled.
    The authors of Boost.Spirit approached this dichotomy, shook it up a bit, and came up with something better. Boost Spirit, already at its third iteration of implementation, harnesses the C++ language and its generative power to enable us to write parser grammar in C++. This allows for the flexibility of using C++, combined with full control of what is parsed how, while maintaining the simplistic abstract representation of what is being parsed. The latest iteration, X3, employs techniques made possible by C++14 to simplify its implementation, to decrease compile times whilst providing the same flexibility of previous versions. I intend to give a general introduction, followed by a partial implementation of a CSS parser, and hope the power of Boost Spirit can convince you to at least give it whirl.
  • 19:30: Break
  • 19:45: Session 2: Using Monoids in C++ (Kristoffel Pirard)
    Effective coders recognise tedious repetition and transform it into reusable patterns. Frameworks, libraries and design patterns arise from it. After the GoF Object Oriented patterns, today we are also learning from the functional programming world. One of the patterns they bumped into is the Monoid: it has its application in addition, accumulation, concatenation, you name it. And it’s a simple one.
    This talk is about how Monoids seem to be everywhere, and how recognising them has influenced my daily practice. It will show a glimpse of the land of functional design patterns and look at practical aspects of using Monoids in C++. I believe it’s important. And I believe there’s a lot more to be discovered.
  • 20:45: Introduction to Sioux, followed by a drink.

Professional C++, 4th Edition
We will be giving away 2 copies of Professional C++, the 4th Edition.

C++ Standard Library Quick Reference
We will also be giving away a copy of C++ Standard Library Quick Reference.

Beginning C++17, From Novice to Professional
And finally, we will also give away a copy of Beginning C++17, From Novice to Professional.

The event is free for everyone, but you need to register for it.

There are 70 seats available for this event.

Note: The deadline for registrations is January 27th, 2019!

Share

Visual Studio 2017 version 15.9 Released

Microsoft has release version 15.9 of Visual Studio 2017. This update includes a few interesting new additions for C++ developers. From their VC++ release notes:

  • We’ve added the “step back” feature in the debugger for C++ in the Visual Studio Enterprise Edition. Step back enables you to go back in time to view the state of your application at a previous point in time.
  • C++ IntelliSense now responds to changes in the remote environment for both CMake and MSBuild projects targeting Linux. As you install new libraries or change your CMake projects, C++ IntelliSense will automatically parse the new headers files on the remote machine for a complete and seamless C++ editing experience.
  • We’ve updated the UWP Desktop Bridge framework packages to match the latest in the Windows Store for all supported architectures, including ARM64.
  • In addition to fixing 60 blocking bugs, we have added support for the range-v3 library with the MSVC 15.9 compiler, available under /std:c++17 /permissive-.
  • The retail VCLibs framework package in Visual Studio has been updated to match the latest available version in the UWP Store.
  • Full support is now available for ARM64 C++ Native Desktop scenarios, including VC++ 2017 Redistributable.
  • We implemented the shortest round-trip decimal overloads of floating-point to_chars() in C++17’s charconv header. For scientific notation, it is approximately 10x as fast as sprintf_s() “%.8e” for floats, and 30x as fast as sprintf_s() “%.16e” for doubles. This uses Ulf Adams’ new algorithm, Ryu.
  • A list of improvements to the standards conformance of the Visual C++ compiler, which potentially require source changes in strict conformance mode, can be found here.

You can find the full release notes here.

Share

Video of my CppCon 2018 Presentation “Writing Standard Library Compliant Data Structures and Algorithms”

On September 27th, 2018 I gave a presentation titled “Writing Standard Library Compliant Data Structures and Algorithms” at CppCon 2018.
You can find the slides here.

The official video is now also available on YouTube. Enjoy 🙂

Share

C++17: Standard Library Algorithms: Changes and Additions

The C++14 Standard Library already contains a wealth of different kinds of algorithms. C++17 adds the following new algorithms and new options to existing algorithms:

  • std::sample()
  • std::for_each_n()
  • Specialized searchers for std::search()
  • Generalized sum algorithms:
    • exclusive_scan()
    • inclusive_scan()
    • transform_exclusive_scan()
    • transform_inclusive_scan()
    • reduce()
    • transform_reduce()
  • Parallel algorithms
  • gcd() / lcm()

I wrote an article for the Visual C++ Team Blog explaining what’s new and what has changed related to algorithms in the C++17 Standard Library in more details.

You can read the article over here.

Share

Slides of my CppCon 2018 Presentation “Writing Standard Library Compliant Data Structures and Algorithms”

On September 27th, 2018 I gave a presentation titled “Writing Standard Library Compliant Data Structures and Algorithms” at CppCon 2018.
The slides of my presentation can be downloaded below:

Share

C/C++ Challenge by Dekimo


The Dekimo C/C++ Challenge is a contest designed to inspire creative and enthousiastic C/C++ Students & Professionals located in Belgium.

The first round is played online. The students and the professionals will compete in separate leagues so that everyone gets a fair chance in competing to be crowned as Belgian C/C++ Champion.

Registration is free and open during the entire duration of the Challenge (6 weeks, September 24 till November 2, 2018).

At the end of the online round, the top 20 players will be invited for the finals.

  • The 10 best Professionals
  • The 10 best Students

The finals will take place on Thursday, November 15, 2018 starting at 18:30 at the EDITx headquarters in Brussels (more details will follow).

The finals are intended to determine the top player in each league. Of course, there are cool prizes to be won that all have to do with smart electronics (a nifty drone for the winner in each league, and a nice voucher for the runners-up!)

Visit the official website for more details.

Share

Next BeCPP UG Meeting Planned For October 25th, 2018

The next meeting of the Belgian C++ Users Group is planned for Thursday October 25th, 2018 at 18:00 at Altran.

Altran ( http://www.altran.com/ ) is sponsoring this event by providing the location, drinks and catering.

Altran Logo

The agenda is as follows:

  • 18:00: Sandwiches.
  • 18:30: Session 1: Writing Standard Library Compliant Data Structures and Algorithms (Marc Gregoire)
    The C++ Standard Library provides a lot of data structures, but it cannot provide every possible data structure or algorithm that you might need. So, sometimes, you might find the need to write your own data structure or algorithm. Since you are writing them yourself, you could give them any interface that suits you. However, wouldn’t it be better to make them compliant with the Standard Library? That way, when you write your own algorithm, you will be able to use that algorithm independently of the type of the container that contains the data for your algorithm. Similarly, if you write a Standard Library compliant data structure, then you will be able to use Standard Library algorithms on the data in your own data structure.
    It’s clear, there are a lot of advantages in making your data structures and algorithms compliant with the Standard Library. We’ll first develop a simple algorithm with our own interface. Then we’ll look into what changes we have to make to transform the interface to be Standard Library compliant. Finally, we’ll demonstrate our adapted algorithm by running it on data in a variety of Standard Library containers.
    In the last part of the presentation we’ll crank it up a notch. We’ll start by writing our own data structure, initially without thinking too much about the Standard Library. Then we’ll look at an overview of the different sets of requirements that the Standard Library imposes for the different types of containers (sequential, associative, and unordered associative). Finally, we’ll adapt our data structure step-by-step to transform it into a Standard Library compliant data structure. This of course includes writing a suitable iterator. Finally, we’ll demonstrate the transformed data structure by running Standard Library algorithms on the data in it.
  • 19:30: Break
  • 19:45: Session 2: Memory Architecture & Performance (Barry Van Landeghem)
    The impact of memory architecture on performance is something which every developer should be aware of. In general improving your code performance is already hard and complex. Computer cache memories have led to introduce a new complexity measure for algorithms and new performance counters for code.
    In this talk we’ll see what data locality is all about and why using data locality can be a great tool for a developer to boost the performance of his/her algorithms/data structures.
    At the end we’ll also at the implications towards parallelism (false sharing/NUMA,…).
  • 20:45: Introduction to Altran, followed by a drink.

Professional C++, 4th Edition
We will be giving away 2 copies of Professional C++, the 4th Edition.

The event is free for everyone, but you need to register for it.

There are 80 seats available for this event.

Note: The deadline for registrations is October 21st, 2018!

Share

C++17 in Detail by Bartłomiej Filipek


C++17 provides developers with a nice selection of new features to write better, more expressive code.

Bartłomiej Filipek has released a book titled “C++17 in Detail” that describes all significant changes in the language and the Standard Library. What’s more, it provides a lot of practical examples so you can quickly apply the knowledge to your code. The book brings you exclusive content about C++17. Additionally, the book provides insight into the current implementation status, compiler support, performance issues and other relevant knowledge to boost your current projects.

The book is a work in progress and is currently 90% finished. The final version should be coming in at around 250 pages. Even though it’s not finished yet, if you buy early, you’ll get free updates later.

Here are the features you’ll learn from reading this book:

Part One: C++17 Language features

  • Fixes and deprecation
  • Language clarification
  • General language features
  • Templates
  • Attributes

Part Two: C++17 The Standard Library

  • std::optional
  • std::variant
  • std::any
  • std::string_view
  • String operations
  • Filesystem
  • Parallel STL
  • Other Changes

Part Three: More Examples and Use Cases

  • Refactoring with std::optional
  • Using if constexpr
  • … and more planned

You can find more information on the book’s website.

Share

C++17 Removed and Deprecated Features

My friend Marius Bancila has posted a nice overview about existing C++ features that have been either removed by C++17 (after being deprecated in a previous version) or that have been deprecated in C++17 so that they could be removed sometime in the future. His list is not exhaustive, but the most important of these removed or deprecated features are mentioned. Removed features include:

  • throw(typeid)
  • std::auto_ptr
  • std::random_shuffle
  • std::unary_function / binary_function
  • std::ptr_fun
  • std::bind1st, bind2nd
  • And more

Deprecated features include:

  • std::uncaught_exception
  • throw()
  • std::unary_negate / binary_negate
  • std::not1 / not2
  • The <codecvt> header
  • And more

Read his blog post here.

Share

My CppCon 2018 Session

I’m happy to say that one of my session proposals for CppCon 2018 has been accepted. The presentation I will give is titled “Writing Standard Library Compliant Data Structures and Algorithms”.

Here is the abstract:

The C++ Standard Library provides a lot of data structures, such as sequential containers (vector, array, deque, list, and forward_list), ordered associative containers (set, map, multiset, and multimap), unordered associative containers (unordered_set, …), and container adaptors (stack, queue, and priority_queue). It also provides a wealth of algorithms for sorting, searching, computing, and so on.

Even so, it cannot provide every possible data structure or algorithm that you might need. So, sometimes, you might find the need to write your own data structure or algorithm. Since you are writing them yourself, you could give them any interface that suits you. However, wouldn’t it be better to make them compliant with the Standard Library? That way, when you write your own algorithm, you will be able to use that algorithm independently of the type of the container that contains the data for your algorithm. Similarly, if you write a Standard Library compliant data structure, then you will be able to use Standard Library algorithms on the data in your own data structure.

It’s clear, there are a lot of advantages in making your data structures and algorithms compliant with the Standard Library. We’ll first develop a simple algorithm with our own interface. Then we’ll look into what changes we have to make to transform the interface to be Standard Library compliant. Finally, we’ll demonstrate our adapted algorithm by running it on data in a variety of Standard Library containers.

In the last part of the presentation we’ll crank it up a notch. We’ll start by writing our own data structure, initially without thinking too much about the Standard Library. Then we’ll look at an overview of the different sets of requirements that the Standard Library imposes for the different types of containers (sequential, associative, and unordered associative). Finally, we’ll adapt our data structure step-by-step to transform it into a Standard Library compliant data structure. This of course includes writing a suitable iterator. Finally, we’ll demonstrate the transformed data structure by running Standard Library algorithms on the data in it.

If you want to write truly generic and flexible data structures and algorithms, then this session is for you.

More information about CppCon (#CppCon) can be found here: https://cppcon.org/.

Share

const auto* versus const auto for Pointer Types

When working with references, C++ developers have been trained to use auto&, const auto&, or auto&& to avoid copies being made. However, when dealing with pointers, developers often do not use auto* but simply use auto instead. With pointers, there is no danger that you make accidental copies of the data, but there are other issues with omitting the *. Also, when working with pointers, there is a big difference between using const auto versus const auto*.

Let’s assume you have the following simple classes:

#include <memory>

class Data {};

class Foo
{
public:
	Foo() : m_data(std::make_unique<Data>()) { }

	Data* GetData() { return m_data.get(); }

private:
	std::unique_ptr<Data> m_data;
};

The GetData() method simply returns a pointer to a Data instance.

When using auto, a lot of developers simply write the following:

Foo foo;
auto d1 = foo.GetData();

The resulting type of d1 is Data*.

I actually recommend to write the following instead:

auto* d2 = foo.GetData();

d2 is also of type Data*, but the benefit is that you immediately see that you are dealing with a pointer. I know, in most IDE’s you can simply hover your mouse over the variable name and it will tell you the exact type. However, sometimes you are not working in an IDE. One such example is when doing code review in an external tool. Most of these tools do not show you that information when hovering over the name of a variable. This makes it a bit more difficult during code review to know that d2 is actually a pointer. When you write auto*, then it’s immediately obvious.

Now, let’s throw const into the mix. Again, most developers will not write the * with auto, so they write the following:

const auto d3 = foo.GetData();

However, this is most of the time not doing what you expect it to do!
Often, when you use const, you want to protect the thing to which the pointer is pointing to. A lot of developers assume that d3 is of type const Data*, but in fact, the type is Data* const, so it’s a const pointer to a non-const Data! Putting the const after the auto as follows doesn’t help, the type is still Data* const:

auto const d4 = foo.GetData();

When you use auto* in combination with const, then it’s behaving as you would expect. For example:

const auto* d5 = foo.GetData();

With this line, d5 is of type const Data* 🙂

If you really want a const pointer instead of const data, you put the const at the end:

auto* const d6 = foo.GetData();

d6 has type Data* const.

And finally, with this syntax you can make both the pointer and the data constant:

const auto* const d7 = foo.GetData();

d7 is of type const Data* const. You cannot achieve this if you omit the *.

All this is something to keep in mind. I’ve seen developers make mistakes against this several times.

Share

Visual Studio 2017 version 15.8 Preview 3 Released

On June 26, 2018, Microsoft released version 15.8 Preview 3 of Visual Studio 2017. Read the announcement here. A few points worth mentioning:

  • Project Loading: Visual Studio version 15.8 Preview 3 brings faster project reloads for all types of projects. Benefits are huge – project unload and reload that used to take more than a minute for large solutions now takes just a few seconds.
  • C++ Templates IntelliSense: Visual Studio 2017 version 15.8 Preview 3 brings IntelliSense for Templates.
  • C++ Refactoring: A new quick-fix lightbulb to convert basic macros to constexpr as a new tool to modernize your C++ code.
  • Improvements for the C++ code analysis tools.
  • C++ Standards: A new, experimental, token-based preprocessor that conforms to C++11 standards (including C99 preprocessor features), enabled with /experimental:preprocessor switch.

Also interesting to know, since 15.7, Visual C++ conforms with the C++ Standard. Read more about this here.

Share

C++17: Attributes

C++17 introduces three new code attributes:

  • [[fallthrough]]
  • [[maybe_unused]]
  • [[nodiscard]]

The first one was discussed in detail in my C++17: Fallthrough in switch statements blog post. The others are briefly explained below.

[[maybe_unused]]

This attribute can be used to mark variables or functions that might be unused to avoid the compiler from generating a warning for such variables and functions.

For example, suppose you have code as follows:

bool DoSomething()
{
    // ... do something ...
    return true;
}

int main()
{
    bool result = DoSomething();
    assert(result);
}

When you build a release build of your code, the assert() macro becomes a no-operation. As such, in release builds, the result variable is unused, while in debug you need the result variable for the assert(). To avoid the compiler warning, use the [[maybe_unused]] attribute as follows:

int main()
{
    [[maybe_unused]] bool result = DoSomething();
    assert(result);
}

This attribute can also be used on functions. Maybe you have a function that is only executed in debug. In such a case, you can mark the function with the attribute. For example:

static bool OnlyUsedInDebug() { return true; }

int main()
{
    assert(OnlyUsedInDebug());
}

When compiling with gcc, the compiler gives the following warning:

warning: ‘bool OnlyUsedInDebug()’ defined but not used [-Wunused-function]

The avoid this warning, use [[maybe_unused]]:

[[maybe_unused]] static bool OnlyUsedInDebug() { return true; }

[[nodiscard]]

This attribute can be used to make sure the caller of a function does not just discard the return value of that function. For example:

bool DoSomething() { return true; }

int main()
{
    DoSomething();
}

The user is not doing anything with the return value of the DoSomething() function, but the compiler will not give any warning about this. Now, the following code adds the [[nodiscard]] attribute:

[[nodiscard]] bool DoSomething() { return true; }

When you try to call it as in the previous main() function, the compiler will complain with something as follows:

warning C4834: discarding return value of function with ‘nodiscard’ attribute

Share

Fixing Unreadable Window Titles in Maximized MFC Ribbon Bar Applications

If you use MFC to create an MFC ribbon bar application, you might notice that when you maximize your application, that the text in the window title bar has a different color compared to a non-maximized window. For example, here is a screenshot of a non-maximized default MFC ribbon bar application created by the Visual Studio project wizard:

When you maximize the window, the result could be as follows:

The text in the title bar becomes white, while it was black in the non-maximized window.
This is a long-standing bug in MFC. Luckily, there is an easy workaround for it. I’ll be using the Windows 7 MFC theme, but similar workarounds can be implemented for the other themes.

First, you need to derive your own class from CMFCVisualManagerWindows7 and override two methods: DrawNcText() and DrawTextOnGlass(). Here is the code:

#pragma once

class CMyVisualManager7 : public CMFCVisualManagerWindows7
{
	DECLARE_DYNCREATE(CMyVisualManager7)

	virtual void DrawNcText(CDC* pDC, CRect& rect, const CString&
		strTitle, BOOL bActive, BOOL bIsRTL, BOOL bTextCenter, BOOL bGlass = FALSE,
		int nGlassGlowSize = 0, COLORREF clrGlassText = (COLORREF)-1) override;

	virtual BOOL DrawTextOnGlass(CDC* pDC, CString strText, CRect rect,
		DWORD dwFlags, int nGlowSize = 0, COLORREF clrText = (COLORREF)-1) override;
};

And here is the implementation:

#include "stdafx.h"
#include "MyVisualManager7.h"

IMPLEMENT_DYNCREATE(CMyVisualManager7, CMFCVisualManagerWindows7)

void CMyVisualManager7::DrawNcText(CDC* pDC, CRect& rect, const CString&
	strTitle, BOOL bActive, BOOL bIsRTL, BOOL bTextCenter, BOOL bGlass /*= FALSE*/,
	int nGlassGlowSize /*= 0*/, COLORREF clrGlassText /*= (COLORREF)-1*/)
{
	if (bGlass && afxGlobalData.bIsWindows7)
	{
		// If we're drawing text on the DWM caption and Windows is Win7 or later, always use default text color
		// (in WinVista, the maximized "aero" caption was black):
		clrGlassText = (COLORREF)-1;
		nGlassGlowSize = 10;
	}

	__super::DrawNcText(pDC, rect, strTitle, bActive, bIsRTL,
		bTextCenter, bGlass, nGlassGlowSize, clrGlassText);
}

BOOL CMyVisualManager7::DrawTextOnGlass(CDC* pDC, CString strText, CRect rect,
	DWORD dwFlags, int nGlowSize /*= 0*/, COLORREF clrText /*= (COLORREF)-1*/)

{
	if (afxGlobalData.bIsWindows7)
	{
		// If we're on Windows 7 or later, always use default color.
		clrText = (COLORREF)-1;
		nGlowSize = 10;
	}

	return __super::DrawTextOnGlass(pDC, strText, rect, dwFlags,
		nGlowSize, clrText);
}

The overridden DrawNcText() method makes sure that the text for the window title is correct, while the overriden DrawTextOnGlass() method makes sure that Quick Access Toolbar controls with
text labels have the correct color.

Once you have your derived class, you have to use it. Your application probably contains something as follows:

CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerWindows7));

Just replace CMFCVisualManagerWindows7 with your CMyVisualManager7:

CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMyVisualManager7));

That’s it.
Just compile and run your application. When you now maximize your window, the color in the title bar will be correct.
For example, here is the previous window maximized:

Looks much better 🙂

Share

C++17: std::string_view

If you have to write a function that accepts a string, what type of parameter will you use? You have a couple of choices:

  • const std::string&: downside is that whenever you call the function, an std::string is expected. If you pass a const char*, an std::string instance will be created implicitly for you.
  • const char*: downside is that if your caller has an std::string, they will have to use c_str() on it to pass a const char* to your function.
  • A const char* overload and a const std::string& overload: downside is that you have to implement two functions. This solution quickly becomes unwieldy if you are writing a method that accepts more than one string as parameter. For example, suppose your method requires two strings as parameters. If you want to overload the method to provide all possible combinations of input argument types, then you end up writing four versions: (const char*, const char*), (const char*, const string&), (const string&, const char*), and (const string&, const string&). This only becomes worse with even more string parameters.

C++17 makes it easy by introducing a new type called std::string_view. From now on, if you are writing a function that accepts a string, use an std::string_view as parameter type. No need to use an std::string_view reference. A string_view is very cheap to copy, so it’s perfectly fine to pass by value. Basically, a string_view just contains a pointer to a string, and its length. A string_view parameter accepts any kind of string, such as a C++ std::string, a C-style const char* string, and a string literal, all without any copying involved!

std::string_view is defined in the <string_view> header. It has a similar interface as the well-known std::string class. However, since a string_view is a read-only view of a string, only the const operations of std::string are supported on a string_view. Additionally, a big advantage of a string_view is that it will never copy a string.

Here is a very brief example of its usage:

#include <iostream>
#include <string_view>

using namespace std;

void ProcessString(string_view myString)
{
    cout << myString; if (myString.size() >= 4)
    {
        cout << "   (Substring: " << myString.substr(2, 2) << ")";
    }
    cout << endl;
}

int main()
{
    string myString1 = "Hello";
    const char* myString2 = "C++";
    ProcessString(myString1);  // C++ string
    ProcessString(myString2);  // C-style string
    ProcessString("World!");   // String literal
}

The output of this piece of code is as follows:

Hello   (Substring: ll)
C++
World!   (Substring: rl)

My book, Professional C++, 4th Edition, explains the std::string_view class in a bit more details. Additionally, it explains all new C++17 features, and much more.

Share

C++17: Fallthrough in switch statements

A C++ switch statement allows execution to fall through from one case to the next case when a break statement is missing. For example:

#include <iostream>

using namespace std;

enum class Mode
{
    Default,
    Custom
};

class Parameters {};

Parameters AskUserForCustomParameters()
{
    cout << "Asking user for custom parameters..." << endl;
    return Parameters();
}

void Process(const Parameters& parameters)
{
    cout << "Processing parameters..." << endl;
}

void DoSomething(Mode mode)
{
    Parameters parameters;  // Create a default set of parameters
    switch (mode)
    {
    case Mode::Custom:
        AskUserForCustomParameters();
    case Mode::Default:
        Process(parameters);
        break;
    }
}

int main()
{
    DoSomething(Mode::Custom);

    cout << endl;

    DoSomething(Mode::Default);
}

Of course, in this case we could just have used an if statement, but that wouldn’t demonstrate fallthrough in switch statements.

If you look at the code, the case for Mode::Custom does not contain a break statement. Some compilers will issue a warning for this kind of fallthrough because it might be unintended and a source of bugs. C++17 introduced a [[fallthrough]] attribute that you can use to specify in code that a fallthrough is intentional and should not generate a warning. Here is the modified fragment:

void DoSomething(Mode mode)
{
    Parameters parameters;  // Create a default set of parameters
    switch (mode)
    {
    case Mode::Custom:
        AskUserForCustomParameters();
        [[fallthrough]];
    case Mode::Default:
        Process(parameters);
        break;
    }
}

You don’t need to use the [[fallthrough]] attribute for empty switch cases. No compiler will issue a warning for fallthrough with empty case statements. For example:

enum class Mode
{
    Default,
    Custom,
    Standard
};

void DoSomething(Mode mode)
{
    Parameters parameters;  // Create a default set of parameters
    switch (mode)
    {
    case Mode::Custom:
        AskUserForCustomParameters();
        [[fallthrough]];
    case Mode::Standard:
    case Mode::Default:
        Process(parameters);
        break;
    }
}

My book, Professional C++, 4th Edition, explains all new C++17 features, and much more.

Share

C++17: std::byte

What is it?

C++17 introduced a new type: std::byte.

Previously, when you needed to access raw memory, you would use an unsigned char or a char data type. However, these data types give the impression that you are working with characters or with numeric values. The new std::byte data type does not convey character or arithmetic semantics, it is just a collection of bits. As such, it’s ideal to represent raw memory. An std::byte only supports initialization from an integral type, and can be converted back to an integral type using std::to_integer(). The only other operations supported are bit-wise operations. Both std::byte and std::to_integer() are defined in <cstddef>.

How to use it?

Let’s look at some short examples. First, here is how you can initialize an std::byte:

#include <cstddef>

int main()
{
    std::byte myByte{ 2 };
}

Next, you can use std::to_integer() to convert an std::byte back to an integral type of your choice:

#include <iostream>
#include <cstddef>

int main()
{
    std::byte myByte{ 2 };
    std::cout << std::to_integer<int>(myByte) << std::endl;
}

The following bitwise operations are supported: <<, >>, |, &, ^, ~, and <<=, >>=, |=, &=, and ^=. Here is an example:

#include <iostream>
#include <cstddef>

using namespace std;

void PrintByte(const byte& aByte)
{
    cout << to_integer<int>(aByte) << endl;
}

int main()
{
    byte myByte{ 2 };
    PrintByte(myByte);	// 2

    // A 2-bit left shift
    myByte <<= 2;
    PrintByte(myByte);	// 8

    // Initialize two new bytes using binary literals.
    byte byte1{ 0b0011 };
    byte byte2{ 0b1010 };
    PrintByte(byte1);	// 3
    PrintByte(byte2);	// 10

    // Bit-wise OR and AND operations
    byte byteOr = byte1 | byte2;
    byte byteAnd = byte1 & byte2;
    PrintByte(byteOr);	// 11
    PrintByte(byteAnd);	// 2
}

Why use it?

You might wonder what the difference is with just using the existing uint8_t instead of std::byte. Well, std::byte is really just a bunch of un-interpreted bits. If you use uint8_t, you are actually interpreting the bits as an 8-bit unsigned numerical value, which might convey the wrong semantics. Also, std::byte will not allow accidental arithmetic on it, while uint8_t does.

Raw memory buffers and interoperability with legacy C-style API’s

If you need a buffer of raw memory, then you can use std::vector<std::byte>.

Additionally, if you need to pass such a buffer to a legacy C-style API accepting, for example, an unsigned char*, then you will have to add a cast. Here is a brief example:

void SomeCApi(unsigned char* buffer, unsigned int size)
{
    for (unsigned char index = 0; index < size; ++index) {
        buffer[index] = index;
    }
}

int main()
{
    std::vector<std::byte> buffer{ 100 };
    SomeCApi(reinterpret_cast<unsigned char*>(&buffer[0]), buffer.size());

    for (const auto& element : buffer) { PrintByte(element); }
}

Conclusion

When you are working with raw bits, use an std::byte instead of an unsigned char or char data type.

Share

Next BeCPP UG Meeting Planned For June 28th, 2018

The next meeting of the Belgian C++ Users Group is planned for Thursday June 28th, 2018 at 18:00 at Amplidata.

Amplidata, a Western Digital company, ( http://amplidata.com/ ) is sponsoring this event by providing the location, drinks and catering.

Amplidata Logo

The agenda is as follows:

  • 18:00: Sandwiches.
  • 18:30: Session 1: Strongly Typed Declarative Bitsets in C++17 (Ewoud van Craeynest)
    The C++ standard states that bool values behave as integral types, that they participate in integral promotions and conversions.
    As a community, we reached the consensus that those integral types aren’t particularly type safe. So, neither are our bools, neither are our bitsets, nor the bits within a bitset. Numbers just being numbers can lead to subtle bugs and impede merciless refactoring.
    This session aims to introduce a strongly typed, declarative bitset type using C++17, by looking at a strongly typed bool and template offset bitfields first.
  • 19:30: Break
  • 19:45: Session 2: The Observer pattern and boost.signals2 (Lieven de Cock)
    The Observer pattern, is one of the many famous GOF design patterns. We will take a look at a minimal implementation, and then enhance that implementation a bit. We briefly touch some potential problems and think about options on how to deal with them. Then we look at a way of avoiding boiler plate code, by using the boost.signals2 library. This header-only boost library will take care of much administration work so we don’t need to reinvent the wheel. No prior knowledge is needed of the observer design pattern, nor the boost.signals2 library.
    Just bring your C++ (11-14-17) skills and … observe.
  • 20:45: Introduction to Amplidata, followed by a drink.

Professional C++, 4th Edition
We will be giving away 2 copies of the recently published new edition of Professional C++, the 4th Edition.

JetBrains
We will also be giving away a JetBrains coupons for 100% discount of a 1 year free personal subscription for any single JetBrains tool/IDE JetBrains.

The event is free for everyone, but you need to register for it.

There are 70 seats available for this event.

Note: The deadline for registrations is June 24th, 2018!

Share