Articles & Books

Quick Q: Syntax of final, override, const with trailing return types

Quick A: The signature of the function is first.

Recently on SO:

Syntax of final, override, const with trailing return types

The correct syntax should be:

  • override and final should appear after the member function declaration, which including the trailing return type specification, i.e.
auto debug(ostream& os=cout) const ->ostream& override final;
  • override and final should not be used with the member function definition outside the class definition, so just remove them:
auto Derived::debug(ostream& os) const ->ostream&
{
  os << "dval: " << dval << endl;
  return os;
}

Overload 138 is now available

ACCU’s Overload journal of April 2017 is out. It contains the following C++ related articles.

Overload 138 is now available

From the journal:

Breadth First, Depth First, Test First
You can approach a problem top-down or bottom-up. Frances Buontempo wonders if algorithms can help us choose the most appropriate direction. by Frances Buontempo

Space invaders in Elm
Elm is a functional language which compiles to JavaScript. Ossi Hanhinen provides an overview. by Ossi Hanhinen

Single Module Builds – The Fastest Heresy in Town
Unity builds can be controversial. Andy Thomason shows how much difference they can make to build times. by Andy Thomason

An Interview: Emyr Williams
CVu has been running a series of interviews. Frances Buontempo interviews the interviewer, Emyr Williams. by Frances Buontempo

(Not Really So) New Niche for C++: Browser!?
How do you run C++ in a browser? Sergey Ignatchenko demonstrates how to use Emscripten. by Sergey Ignatchenko

Contractual Loopholes
Compilers can optimise away functions you may want to time. Deák Ferenc explores ways to stop this happening. by Deák Ferenc

All About the Base
Representing numbers presents many choices. Teedy Deigh counts the ways. by Teedy Deigh

C++ Jobs and Predictions—Bartlomiej Filipek

Is C++ job market falling or growing? Since billions of lines of code are already written it's not possible to disappear in a second. So what's the current state and the future?

C++ Jobs and Predictions

by Bartlomiej Filipek

From the article:

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

Understand ranges better with the new Cartesian Product adaptor—Jonathan Boccara

The future explained:

Understand ranges better with the new Cartesian Product adaptor

by Jonathan Boccara

From the article:

A couple of days ago, the range-v3 library got a new component: the view::cartesian_product adaptor.

Understanding what this component does, and the thought process that went through its creation is easy and will let you have a better grasp of the range library. (Note that you could just as well understand all the following by looking at the zip adaptor. But cartesian_product is brand new, so let’s discover this one, in order to hit two birds with one stone)...

An Introduction to Reflection in C++—Jackie Kay

What's the status of reflection in C++?

An Introduction to Reflection in C++

by Jackie Kay

From the article:

Stop me if you’ve heard this one before. You are working on a messaging middleware, a game engine, a UI library, or any other large software project that has to deal with an ever-growing, ever-changing number of objects. These objects have many different qualities but can be grouped by their functionality: they can be sent across the network or collided with or rendered.

Because you are a good programmer who believes in the DRY principle, you want to write the “action” code that does the stuff on these objects without repetition, and plug in specific Message types or Renderable types into your generic pipeline at the appropriate places. It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes...

Final Classes—Arne Mertz

Some thoughts about final classes.

Final Classes

by Arne Mertz

From the article:

A few days ago, a colleague asked me if it was wise to make every class a final class. Here is a more sophisticated answer than I could give at that time...

Quick Q: std::move with std::shared_ptr in lambda

Quick A: Lambda captures are const by default, and it is not possible to move a const.

Recently on SO:

std::move with std::shared_ptr in lambda

The captured variable ptr in a lambda is by default const, i.e. the type of ptr is const std::shared_ptr<int>.

std::move cannot move out const objects, so a copy is created instead.

If you really want to move it, the ptr must be allowed to be mutable:

auto lambda = [ptr]() mutable {

Quick Q: Are the experimental features of modern C++ reliable for long-term projects?

Quick A: No

Recently on SO:

Are the experimental features of modern C++ reliable for long-term projects?

Is it guaranteed that all compliant compilers have the same experimental features?
No, experimental features are optional.
Are experimental features prone to big changes that make them unreliable?
Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.

Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).