intermediate

Fast Polymorphic Collections with Devirtualization -- Joaquín M López Muñoz

munoz.pngStill on the theme of "contiguous enables fast," a followup on the recent "Fast Polymorphic Collections" article:

Fast Polymorphic Collections with Devirtualization

by Joaquín M López Muñoz

From the article:

The poly_collection template class we implemented for fast handling of polymorphic objects can be potentially speeded up in the case where some of the derived classes it manages are known to the compiler at the point of template instantiation...

Allowing for the specification of a list of statically known derived class types as part of a poly_collection instantiation opens up possibilities for internal performance optimizations that do not impact the usage interface of this template class. The actual improvements achieved depend very much on the compiler being used, but in general are greater when passing polymorphic functors (such as generic lambdas) to for_each and qualifying virtual functions as final where possible.

Introducing emplacer -- Tim

Another nice way to have a polymorphic collection without sacrificing that performance-precious contiguous memory layout:

Introducing emplacer: allocate subtypes of an abstract base class directly in a container

by Tim

From the article:

So I complained to my friend Jeremy that C++ should be able to do this. This isn't Java, I shouldn't have to do a separate allocation for each object...

As alluded to earlier, you can also use it in containers. Here's an example:

std::vector<ShapeAny> shapes;

shapes.emplace(shapes.end())->emplace<Rect>(3, 4);
shapes.emplace(shapes.end())->emplace<Square>(3);

//emplace returns reference to *this, so you can use it like this too
shapes.push_back(ShapeAny().emplace<Rect>(5, 6));
shapes.push_back(ShapeAny().emplace<Circle>(1));

for (auto shape: shapes) {
  std::cout << shape->area() << std::endl;
}

Fast Polymorphic Collections -- Joaquín M López Muñoz

munuz-poly.PNGOn the theme of "contiguous enables fast":

Fast Polymorphic Collections

by Joaquín M López Muñoz

From the article:

poly_collection behaves excellently and is virtually not affected by the size of the container. For n < 105, the differences in performance between poly_collection and a std::vector of std::unique_ptrs are due to worse virtual call branch prediction in the latter case; when n > 105, massive cache misses are added to the first degrading factor.

A C error handling style that plays nice with C++ exceptions

If you've ever wondered why someone might throw an exception from a destructor, this article provides a legitimate example:

A C Error Handling Style that Plays Nice with C++ Exceptions

by Stefanus Du Toit

From the article:

By choosing a particular convention for a C API's error handling, we were able to very conveniently translate errors from the C API to C++ exceptions. ... Every experienced C++ programmer I know has opinions on how errors should be handled. I've found this style to be quite useful when layering C++ on top of C, and I think there's some beauty in the interplay between C and C++ here.

 

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