Articles & Books

noexcept: what for? -- Andrzej KrzemieĊ„ski

From the desk of Andrzej:

noexcept -- what for?

by Andrzej Krzemieński

From the article:

In this post I would like to share my observation on where using noexcept really adds value. It is less often than what one might expect, and it does not have that much to do with throwing or not throwing exceptions. The conclusion surprises me a bit, and I hesitate to present it because it is counter to the advice I hear from people I consider authorities on the subject...

Async-Await in C++ -- Paolo Severini

severini-await.PNGParis, April 2014: Paolo Severini explores the Async-Await pattern and the related proposal for C++17, showing also an example by using Visual Studio 2013 November CTP.

Async-Await in C++

by Paolo Severini

From the article:

... what about native [C++] programming? Is there anything like async/await that we can use with our futures? We can find the answer in N3858, another proposal made by Gustafsson et al. for C++17.

This time the changes proposed are to the language itself and not just to the library. The idea is to introduce the equivalent of C# async methods in the form of resumable functions. They can be thought as the basis to add to C++ the support for real co-routines, and are not strictly related to the <future> library, even though they have being defined especially to improve the usability of futures and promises...

Writing a simple bar graph widget in Qt

Recently I had to implement a simple version of a bar graph widget in Qt:

Writing a bar graph widget in Qt

by Jens Weller

From the Article:

Today I had a little fun with Qt and wrote a widget for displaying a bar graph. I have two different situations where I need the bar graph in my back end: displaying the votes a single talk got, and displaying one big bar graph of all the talks.

Preferring STL algorithms from algorithm and numeric -- makramkd

(Related note: If you haven't yet watched and grokked Sean Parent's wonderful C++ Seasoning talk from last fall's GoingNative conference, do yourself a favor and watch it. You will find it eye-opening. If you have already watched it, you might still find it worth a re-watch to fully absorb.)

Here's a nice case study of why not to roll your own algorithms, when C++ comes with a treasure chest full of pre-written, pre-debugged, and pre-optimized (in a good way) standard algorithms in the box:

Preferring STL algorithms from algorithm and numeric

by makramkd

From the article:

This post isn’t meant to be a documentation of the algorithm and numeric headers: you can find those readily at cppreference. In this post I’m going to try to convince people that write very similar algorithms to those in the standard library to not use these algorithms in production code, and to prefer ones from the STL.

Let’s get the show on the road. I’m going to start with the most simple one, because I just want to get my point across.

Understanding the New Set and Map Containers in the C++11 Standard Library -- S Clamage and D Gove

On the Oracle Tech Network, a nice reminder of the still-"new"-to-some hash-based containers, co-authored by the chair of the U.S. C++ standards committee:

Understanding the New Set and Map Containers in the C++11 Standard Library

by Steve Clamage and Darryl Gove

From the article:

One of the areas in the new C++ standard that has seen the most enhancement is the Standard Library. The functionality that is most likely to be immediately useful to developers is the additions to the container classes. This article describes the new set and map containers.

Quick Q: Why does this function take a parameter by value? -- StackOverflow

A classic on SO:

Why do we copy then move?

I saw code somewhere in which someone decided to copy an object and subsequently move it to a data member of a class. This left me in confusion in that I thought the whole point of moving was to avoid copying. Here is the example:

struct S
{
    S(std::string str) : data(std::move(str))
    {}
};

Here are my questions:

  • Why aren't we taking an rvalue-reference to str?
  • Won't a copy be expensive, especially given something like std::string?
  • What would be the reason for the author to decide to make a copy then a move?
  • When should I do this myself?

The standard way of converting between numbers and strings in C++11 -- Marius Bancila

Quick: Would you resort to stringstream? But that's so C++98... and so hard.

More people need to know about to_string and its cousins. Marius Bancila takes us for a short tour:

The standard way of converting between numbers and strings in C++11

by Marius Bancila

From the article:

C++11 provides several standard functions for converting numbers to strings and strings to numbers, all of them available in the <string> header.

For converting numbers to strings there are two new overloaded functions: to_string() and to_wstring(). They take one argument of various numeric types (int, long, long long, double, long double, etc.) and return either a std::string or a std::wstring with the number converted to text. ...

For the other way around of converting strings to numbers there are several overloaded methods (taking either a std::string or a std::wstring): ...

Ponder the use of unique_ptr to enforce the Rule of Zero -- Marco Arena

Marco Arena points out an important difference between shared_ptr and unique_ptr regarding polymorphic deletion. The article also shows two ways to equip unique_ptr with a type-erased deleter, one with no usage of dynamic dispatching.

Ponder the use of unique_ptr to enforce the Rule of Zero

by Marco Arena

I read the article "Enforcing the Rule of Zero" from latest Overload (of ACCU) and I'd like to point out something that I misapprehended at a first reading. ... a clever point the author underlines is about polymorphic deletion: what to do when we want to support polymorphic deletion, or when our classes have virtual functions? ...

Then the author suggests to use a shared_ptr: ...