Articles & Books

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
}

C++17 In Detail - new book on C++ -- Bartlomiej Filipek

Learn the Exciting Features of The New C++ Standard with a new Book on C++

C++17 in Detail

by Bartlomiej Filipek

From the introduction:

C++17 was officially standardised in December 2017, giving us - developers - a wealth of new features to write better code.

This book describes all significant changes in the language and the Standard Library. What's more, it provides a lot of practical examples so you can quickly apply the knowledge to your code.

Overload 144 is now available

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

Overload 146 is now available

From the journal:

Should I Lead by Example?
Stuck on a problem? Frances Buontempo considers where to turn to for inspiration.

Cache-Line Aware Data Structures.
Structuring your program to consider memory can improve performance. Wesley Maness and Richard Reich demonstrate this with a producer-consumer queue.

miso: Micro Signal/Slot Implementation.
The Observer pattern has many existing implementations. Deák Ferenc presents a new implementation using modern C++ techniques.

(Re)Actor Allocation at 15 CPU Cycles.
(Re)Actor serialisation requires an allocator. Sergey Ignatchenko, Dmytro Ivanchykhin and Marcos Bracco pare malloc/free down to 15 CPU cycles.

How to Write a Programming Language: Part 2, The Parser.
We’ve got our tokens: now we need to knit them together into trees. Andy Balaam continues writing a programming language with the parser.

Compile-time Data Structures in C++17: Part 1, Set of Types.
Compile time data structures can speed things up at runtime. Bronek Kozicki details an implementation of a compile time set.

Should I Use Overloads or Default Parameters?--Jonathan Boccara

The answer is not obvious.

Should I Use Overloads or Default Parameters?

by Jonathan Boccara

From the article:

“Should I use overloads or default parameters”, haven’t you asked yourself that question?

When designing an interface where the user can leave the value of an argument up to the API, two approaches are possible:

Using a default parameters:

voiddrawPoint(int x, int y, Color color = Color::Black);
void drawPoint(int x, int y, Color color = Color::Black);

And using overloading:

void drawPoint(int x, int y); // draws a point in black
void drawPoint(int x, int y, Color color);

Which approach is cleaner? Which expresses better the intentions of the interface? Or is it just a matter of style?

This may be subjective, but I’m under the impression that overloading tends to have better popularity than default parameters amongst C++ developers. But I believe that both features have their usages, and it’s usefulto see what makes one or the other more adapted to a given situation.

A Case for p0424 - Sane C++ Serialization -- Wojciech Szeszol

Serialization was always a problematic topic in C++. Is it going to change in the future? Check out to see how the string literals as the template parameters can help here.

A Case for p0424 - Sane C++ Serialization

By Wojciech Szeszol

From the article:

Probably every C# developer knows how versatile the Newtonsoft.Json or the standard C# serialization libraries are. The serialization with DataContract or JsonProperty is easy to write, maintain and quite efficient. When we compare it with what C++ have to offer, the latter looks very poorly. We have selection of dedicated reflection/serialization libraries [...]. Unfortunately all of them come with different sets of drawbacks: they require the serialization methods to be written manually, force usage of ugly macros, require manual registration of the structures and their fields or involve additional compilation step for the schema definitions. [...] This may change with the new C++20 standard and the introduction of the string literals as the template parameters.

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