intermediate

Modern C++ Features – Quality-of-Life Features—Arne Mertz

Some to help, some to enable.

Modern C++ Features – Quality-of-Life Features

by Arne Mertz

From the article:

With the new C++ standards, we got a lot of features that feel like “quality-of-life” features. They make things easier for the programmer but do not add functionality that wasn’t already there. Except, some of those features do add functionality we couldn’t implement manually.

Some of those quality-of-life features are really exactly that. The standard often describes them as being equivalent to some alternative code we can actually type. Others are mostly quality-of-life, but there are edge cases where we can not get the effect by hand, or the feature is slightly superior to the manual implementation.

I will concentrate on core language features here, since most library features are implementable using regular C++. Only a few library features use compiler intrinsics...

Quick Q: C++11 auto: what if it gets a constant reference?

Quick A: auto never deduces a reference.

Recently on SO:

C++11 auto: what if it gets a constant reference?

Read this article: Appearing and Disappearing consts in C++

Type deduction for auto variables in C++0x is essentially the same as for template parameters. (As far as I know, the only difference between the two is that the type of auto variables may be deduced from initializer lists, while the types of template parameters may not be.) Each of the following declarations therefore declare variables of type int (never const int):

auto a1 = i;
auto a2 = ci;
auto a3 = *pci;
auto a4 = pcs->i;

During type deduction for template parameters and auto variables, only top-level consts are removed. Given a function template taking a pointer or reference parameter, the constness of whatever is pointed or referred to is retained:

template<typename T>
void f(T& p);

int i;
const int ci = 0;
const int *pci = &i;

f(i);               // as before, calls f<int>, i.e., T is int
f(ci);              // now calls f<const int>, i.e., T is const int
f(*pci);            // also calls f<const int>, i.e., T is const int

This behavior is old news, applying as it does to both C++98 and C++03. The corresponding behavior for auto variables is, of course, new to C++0x:

auto& a1 = i;       // a1 is of type int&
auto& a2 = ci;      // a2 is of type const int&
auto& a3 = *pci;    // a3 is also of type const int&
auto& a4 = pcs->i;  // a4 is of type const int&, too

Since you can retain the cv-qualifier if the type is a reference or pointer, you can do:

auto& my_foo2 = GetFoo();

Instead of having to specify it as const (same goes for volatile).

Edit: As for why auto deduces the return type of GetFoo() as a value instead of a reference (which was your main question, sorry), consider this:

const Foo my_foo = GetFoo();

The above will create a copy, since my_foo is a value. If auto were to return an lvalue reference, the above wouldn't be possible.

How To Use std::visit With Multiple Variants—Bartlomiej Filipek

Variant utility.

How To Use std::visit With Multiple Variants

by Bartlomiej Filipek

From the article:

std::visit is a powerful utility that allows you to call a function over a currently active type in std::variant. It does some magic to select the proper overload, and what’s more, it can support many variants at once.

Let’s have a look at a few examples of how to use this functionality...

Quick Q: C++ constexpr - Value can be evaluated at compile time?

Quick A: if parameter are not known at compile time, it is like a normal function

Recently on SO:

C++ constexpr - Value can be evaluated at compile time?

The quoted wording is a little misleading in a sense. If you just take PlusOne in isolation, and observe its logic, and assume that the inputs are known at compile-time, then the calculations therein can also be performed at compile-time. Slapping the constexpr keyword on it ensures that we maintain this lovely state and everything's fine.

But if the input isn't known at compile-time then it's still just a normal function and will be called at runtime.

So the constexpr is a property of the function ("possible to evaluate at compile time" for some input, not for all input) not of your function/input combination in this specific case (so not for this particular input either).

It's a bit like how a function could take a const int& but that doesn't mean the original object had to be const. Here, similarly, constexpr adds constraints onto the function, without adding constraints onto the function's input.

Admittedly it's all a giant, confusing, nebulous mess (C++! Yay!). Just remember, your code describes the meaning of a program! It's not a direct recipe for machine instructions at different phases of compilation.

(To really enforce this you'd have the integer be a template argument.)

Modern C++: 7 Ways to Fake It Until You Have It—Jonathan Boccara

If you want.

Modern C++: 7 Ways to Fake It Until You Have It

by Jonathan Boccara

From the article:

Do you wish you had a later version of C++ in your production code? If you do, you’re not alone: a lot of C++ developers today don’t work with a compiler that supports the latest version of the standard.

It could be for many reasons: perhaps you have a lot of legacy code to migrate, or your clients do, or your hardware doesn’t have the adequate infrastructure yet. The point is, you can’t benefit from the latest features that the language offers, and that’s a shame because some of them would surely make your code more expressive.

But even if you can’t use those features, you don’t have to give up on their benefits. At least some of their benefits. There are way you could use the ideas of the new features in your code, to convey your intents more precisely.

Sure enough, it’s not as good as having them natively, which is why updating your compilers is still a necessity. But in the meantime, here are 7 ways to emulate those features, that will improve your code at a minimal cost...

Spaceship Operator—Simon Brand

The future?

Spaceship Operator

by Simon Brand

From the article:

You write a class. It has a bunch of member data. At some point, you realise that you need to be able to compare objects of this type. You sigh and resign yourself to writing six operator overloads for every type of comparison you need to make. Afterwards your fingers ache and your previously clean code is lost in a sea of functions which do essentially the same thing. If this sounds familiar, then C++20’s spaceship operator is for you. This post will look at how the spaceship operator allows you to describe the strength of relations, write your own overloads, have them be automatically generated, and how correct, efficient two-way comparisons are automatically rewritten to use them...

How to Design Early Returns in C++ (Based on Procedural Programming)—Jonathan Boccara

What do you think?

How to Design Early Returns in C++ (Based on Procedural Programming)

by Jonathan Boccara

From the article:

Travelling back from ACCU conference a couple of weeks ago, one of the insights that I’ve brought back with me is from Kevlin Henney’s talk Procedural Programming: It’s Back? It Never Went Away. It’s surprisingly simple but surprisingly insightful, and it has to do with early return statements...

Quick Q: What are copy elision and return value optimization?

Quick A: they are common optimizations that a compiler can do behind the scenes to avoid copying in certain cases.

Recently on SO:

What are copy elision and return value optimization?

Copy elision is an optimization implemented by most compilers to prevent extra (potentially expensive) copies in certain situations. It makes returning by value or pass-by-value feasible in practice (restrictions apply).

It's the only form of optimization that elides (ha!) the as-if rule - copy elision can be applied even if copying/moving the object has side-effects.

The following example taken from Wikipedia:

struct C {
  C() {}
  C(const C&) { std::cout << "A copy was made.\n"; }
};

C f() {
  return C();
}

int main() {
  std::cout << "Hello World!\n";
  C obj = f();
}

Depending on the compiler & settings, the following outputs are all valid:

Hello World!
A copy was made.
A copy was made.
Hello World!
A copy was made.
Hello World!

This also means fewer objects can be created, so you also can't rely on a specific number of destructors being called. You shouldn't have critical logic inside copy/move-constructors or destructors, as you can't rely on them being called.

If a call to a copy or move constructor is elided, that constructor must still exist and must be accessible. This ensures that copy elision does not allow copying objects which are not normally copyable, e.g. because they have a private or deleted copy/move constructor.

C++17: As of C++17, Copy Elision is guaranteed when an object is returned directly:

struct C {
  C() {}
  C(const C&) { std::cout << "A copy was made.\n"; }
};

C f() {
  return C(); //Definitely performs copy elision
}
C g() {
    C c;
    return c; //Maybe performs copy elision
}

int main() {
  std::cout << "Hello World!\n";
  C obj = f(); //Copy constructor isn't called
}