performance

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
}

CppCon 2017: How to Write a Custom Allocator—Bob Steagall

Have you registered for CppCon 2018 in September? Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2017 for you to enjoy. Here is today’s feature:

How to Write a Custom Allocator

by Bob Steagall

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

You'd like to improve the performance of your application with regard to memory management, and you believe this can be accomplished by writing a custom allocator. But where do you start? Modern C++ brings many improvements to the standard allocator model, but with those improvements come several issues that must be addressed when designing a new allocator.

This talk will provide guidance on how to write custom allocators for the C++14/C++17 standard containers. It will cover the requirements specified by the standard, and will describe the facilities provided by the standard to support the new allocator model and allocator-aware containers. We'll look at the issues of allocator identity and propagation, and examine their implications for standard library users, standard library implementers, and custom allocator implementers. We'll see how a container uses its allocator, including when and how a container's allocator instance propagates. This will give us the necessary background to describe allocators that implement unusual semantics, such as a stateful allocator type whose instances compare non-equal. Finally, the talk will provide some guidelines for how to specify a custom allocator's public interface based on the semantics it provides.

Announcing “trivially relocatable”—Arthur O’Dwyer

Do you want this?

Announcing “trivially relocatable”

by Arthur O’Dwyer

From the article:

Frequent users of Compiler Explorer, a.k.a. godbolt.org, may have noticed that a few days ago a new compiler appeared in its dropdown menu. “x86-64 clang (experimental P1144)” is a branch of Clang which I have patched to support the concept of “trivially relocatable types,” as described in my C++Now 2018 talk and as proposed for standardization in my upcoming paper P1144 “Object relocation in terms of move plus destroy” (coauthored with Mingxin Wang)...

How to Construct C++ Objects Without Making Copies—Miguel Raggi

Avoiding copies.

How to Construct C++ Objects Without Making Copies

by Miguel Raggi

From the article:

C++ references are a powerful but tricky tool: used correctly, they can improve performance with little impact on the clarity of code. But used badly, they can hide performance issues, or even send a peaceful program into the realm of undefined behaviour.

In this post, we will explore how to use the various references of C++ to minimize copies when constructing an object that holds a value, and how in some cases we can even reach zero copies.

This article assumes that you’re familiar with move semantics, lvalue, rvalue and forwarding references. If you’d like to be refreshed on the subject, you can take a look at lvalues, rvalues and their references.

C++ Weekly Episode 125: The Optimal Way To Return From A Function—Jason Turner

Episode 125 of C++ Weekly.

The Optimal Way To Return From A Function

by Jason Turner

About the show:

In this episode of C++ Weekly Jason investigates the possible methods that one of two string values might be returned from a function. Which option is best? Which option can the compiler optimize the most? Do we take one return path or multiple return paths? Should a ternary be used?

CppCon 2017: Delegate this! Designing with delegates in modern C++—Alfred Bratterud

Have you registered for CppCon 2018 in September? Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2017 for you to enjoy. Here is today’s feature:

Delegate this! Designing with delegates in modern C++

by Alfred Bratterud

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Designing a fast IP stack from scratch is hard. Using delegates made it all easier for IncludeOS, the open source library operating system written from scratch in modern C++. Our header-only delegates are just as fast as C-style function pointers, compatible with std::function, and allows any object to delegate work to stateful member functions without knowing anything about the class they belong to. We use delegates for everything from routing packets to creating REST endpoints, and most importantly to tie the whole IP stack together. In this talk we’ll show you how we use delegates in IncludeOS, discuss pitfalls and alternatives, and give you all you need to get started.

CppCon 2017: Coroutines: what can’t they do?—Toby Allsopp

Have you registered for CppCon 2018 in September? Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2017 for you to enjoy. Here is today’s feature:

Coroutines: what can't they do?

by Toby Allsopp

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Coroutines are coming. They're coming for your asynchronous operations. They're coming for your lazy generators. This much we know. But once they're here, will they be satisfied with these offerings? They will not. They will require feeding, lest they devour our very souls. We present some fun ways to keep their incessant hunger at bay. I, for one, welcome our new coroutine overlords.

The Coroutines Technical Specification is an experimental extension to the C++ language that allows functions to be suspended and resumed, with the primary aim of simplifying code that invokes asynchronous operations. We present a short introduction to Coroutines followed by some possibly non-obvious ways they can help to simplify your code.

Have you ever wanted to elegantly compose operations that might fail? Coroutines can help. Have you ever wished for a zero-overhead type-erased function wrapper? Coroutines can help. We show you how and more.