Articles & Books

Quick Q: What does it mean to return a reference?

Quick A: The returned variable can be modified.

Recently on SO:

What does it mean to return a reference?

It means you return by reference, which is, at least in this case, probably not desired. It basically means the returned value is an alias to whatever you returned from the function. Unless it's a persistent object it's illegal.

For example:

int& foo () {
    static int x = 0;
    return x;
}

//...
int main()
{
    foo() = 2;
    cout << foo();
}

would be legal and print out 2, because foo() = 2 modifies the actual value returned by foo.

However:

int& doit () {
    int x = 0;
    return x;
}

would be illegal (well, accessing the returned value would), because x is destroyed when the method exits, so you'd be left with a dangling reference.

Returning by reference isn't common for free functions, but it is for methods returning members. For example, in the std, the operator [] for common containers return by reference. For example, accessing a vector's elements with [i] returns an actual reference to that element, so v[i] = x actually changes that element.

Also, I hope that "is essentially equal to this code" means that they're semantically sort of (but not really) similar. Nothing more.

Inline Namespaces 101--Jonathan Müller

Obscure feature? Not for long.

Inline Namespaces 101

by Jonathan Müller

From the article:

Almost three years ago — wow, how time flies — I blogged about namespace aliases and called them one of C++ most underrated features (which probably was a bit of a click bait).

Let’s talk about some other namespace feature, that is, well, not quite underrated, but relatively obscure: inline namespace. They are namespaces that don’t really introduce a scope, except when they do.

So what can you do with them?

How to teach C++--Marius Elvert

Do you have a way?

How to teach C++

by Marius Elvert

From the article:

In the closing Keynote of this year’s Meeting C++, Nicolai Josuttis remarked how hard it can be to teach C++ with its ever expanding complexity. His example was teaching rookies about initialization in C++, i.e. whether to use assignment =, parens () or curly braces {}. He also asked for more application-level programmers to participate.

Well, I am an application programmer, and I also have experience with teaching C++. Last year I held a C++ introductory course for experienced C programmers who mostly had never used C++ before. From my experience, I can completely agree with what Nico had to say about teaching C++. The language and its subtlety can be truly overwhelming.

Most of the complexity in C++ boils down to tuning your code for optimal performance. We cannot just leave that out, can we? After all, the sole reason to use C++ is performance, right?

How to Design Function Parameters That Make Interfaces Easier to Use (1/3)--Jonathan Boccara

Readability is important.

How to Design Function Parameters That Make Interfaces Easier to Use (1/3)

by Jonathan Boccara

From the article:

When you look at an function in an interface, 3 prominent things give you indications about how to use it: its name, its parameters and its return type. And when you look at a piece of code calling that function, it’s just its name and its function parameters.

We’ve already covered in details how to give good names to the components of your code. Now we’re going to examine how to design function parameters in a way that both your interfaces and the code that calls them are as expressive as can be.

Summed up in one sentence, you want to make the decision of what arguments to pass to your functions a no-brainer.

There are a lot of things to say about how to achieve this. So much so that you will find the contents broken down into 3 articles in order to make it easier to digest:

  • Part 1: interface-level parameters, one-parameter functions, const parameters,
  • Part 2: calling contexts, strong types, parameters order,
  • Part 3: packing parameters, processes, levels of abstraction.

To support this series I’ve taken many examples from interfaces I’ve worked on, except that I’ve stripped out all domain aspects to make them both simpler and disclosable...

A zero cost abstraction?--Josh Peterson

Safe and performant?

A zero cost abstraction?

by Josh Peterson

From the article:

Recently Joachim (CTO at Unity) has been talking about “performance by default”, the mantra that software should be as fast as possible from the outset. This is driving the pretty cool stuff many at Unity are doing around things like ECS, the C# job system, and Burst (find lots more about that here).

One question Joachim has asked internally of Unity developers is (I’m paraphrasing here): “What is the absolute lower bound of time this code could use?” This strikes me as a really useful way to think about performance. The question changes from “How fast is this?” to “How fast could this be?”. If the answers to those two questions are not the same, the next question is “Do we really need the additional overhead?”

Another way to think about this is to consider the zero-cost abstraction, a concept much discussed in the C++ and Rust communities. Programmers are always building abstractions, and those abstractions often lead to the difference between “how fast it is” and “how fast it could be”. We want to provide useful abstractions that don’t hurt performance...

San Diego Committee Meeting: A Trip Report--Corentin Jabot

Trip report.

San Diego Committee Meeting: A Trip Report

by Corentin Jabot

From the article:

As I left Rapperswil earlier this year, I said very firmly that I would not go to the San Diego Meeting.

Crossing an ocean to work on C++ 12 hours a day for a week is indeed madness.

And so naturally, I found myself in a San Diego hotel straight from the 60s, to do some C++ for a week. With the exception of the author of this blog, all people there are incredibly smart and energetic, and so a lot of great work was done...

Trip Report: Freestanding in San Diego--Ben Craig

One more report.

Trip Report: Freestanding in San Diego

by Ben Craig

From the article:

All three are dealing with "freestanding". I've been working for the last year or so trying to redefine freestanding in a way that would be useful to more people. I have personal experience using C++ in various operating system kernels / drivers, and a bit of experience working on micro controllers and digital signal processors, so that's where my papers focused. At the CppCon 2018 SG14 meeting, some GPU companies have said that my definitions are useful for their architectures (with some tweaks), and I've heard from several other people that my definitions are even useful in some environments where performance and determinism are key, even when there is an OS. I'm still trying to figure out if and how to incorporate all these groups into one thing that could get standardized.

I pitched "Freestanding Proposal" at my first WG21 meeting was November of 2017 in Albuquerque. I was an unknown then. San Diego was my third WG21 meeting. All the papers and interviews and trip reports have now made it where people were asking me about freestanding quite frequently. There were a few times I got stopped while walking around by someone I had never talked to before, and they knew who I was, and asked about freestanding. I found this very flattering. I'm thrilled (and terrified) that my work is getting such visibility...

The Amazing Performance of C++17 Parallel Algorithms, is it Possible?--Bartlomiej Filipek

Are you using it?

The Amazing Performance of C++17 Parallel Algorithms, is it Possible?

by Bartlomiej Filipek

From the article:

With the addition of Parallel Algorithms in C++17, you can now easily update your “computing” code to benefit from parallel execution. In the article, I’d like to examine one STL algorithm which naturally exposes the idea of independent computing. If your machine has 10-core CPU, can you always expect to get 10x speed up? Maybe more? Maybe less? Let’s play with this topic.