Blog

CppCast Episode 163: Sourcetrail with Eberhard Gräther

Episode 163 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Eberhard Gräther to discuss his work on Sourcetrail, a cross-platform source explorer for C++ code.

CppCast Episode 163: Sourcetrail with Eberhard Gräther

by Rob Irving and Jason Turner

About the interviewee:

Eberhard Gräther is software developer, user experience designer and founder at Coati Software. He started programming C++ during his undergraduate CS degree at Salzburg University of Applied Sciences, majoring in game development. During multiple internships in the Google Chrome Team he worked on tools for rendering performance analysis. He then specialized in Human Computer Interaction and developer tooling during a Master's degree, where he started working on Sourcetrail, a cross-platform source explorer for faster understanding of unfamiliar source code.

CppCon 2017: C++ atomics, from basic to advanced. What do they really do?—Fedor Pikus

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:

C++ atomics, from basic to advanced. What do they really do?

by Fedor Pikus

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++11 introduced atomic operations. They allowed C++ programmers to express a lot of control over how memory is used in concurrent programs and made portable lock-free concurrency possible. They also allowed programmers to ask a lot of questions about how memory is used in concurrent programs and made a lot of subtle bugs possible.

This talk analyzes C++ atomic features from two distinct points of view: what do they allow the programmer to express? what do they really do? The programmer always has two audiences: the people who will read the code, and the compilers and machines which will execute it. This distinction is, unfortunately, often missed. For lock-free programming, the difference between the two viewpoints is of particular importance: every time an explicit atomic operation is present, the programmer is saying to the reader of the program "pay attention, something very unusual is going on here." Do we have the tools in the language to precisely describe what is going on and in what way it is unusual? At the same time, the programmer is saying to the compiler and the hardware "this needs to be done exactly as I say, and with maximum efficiency since I went to all this trouble."

This talk starts from the basics, inasmuch as this term can be applied to lock-free programming. We then explore how the C++ lock-free constructs are used to express programmer's intent clearly (and when they get in the way of clarity). Of course, there will be code to look at and to be confused by. At the same time, we never lose track of the fact that the atomics are one of the last resorts of efficiency, and the question of what happens in hardware and how fast does it happen is of paramount importance. Of course, the first rule of performance — "never guess about performance!" — applies, and any claim about speed must be supported by benchmarks.

If you never used C++ atomics but want to learn, this is the talk for you. If you think you know C++ atomics but are unclear on few details, come to fill these few gaps in your knowledge. If you really do know C++ atomics, come to feel good (or to be surprised, and then feel even better).

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 break an ABI and keep your users happy—Gennadiy Rozental

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 break an ABI and keep your users happy

by Gennadiy Rozental

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Technical debt is the bane of most established libraries, whether it is standard library or boost or local library developed in house. Paying this debt is expensive and in many cases seems infeasible.

As a result of several (justified at the time) decisions Google accumulated serious technical debt in how we use std::string. This became a blocking issue in our effort to open source Google’s common libraries.

To fix this we needed to break libstdc++ std::string ABI. This is the story of how we survived it kept Google still running.

CopperSpice: Thread Safety

New video on the CopperSpice YouTube Channel:

Thread Safety

by Barbara Geller and Ansel Sermersheim

About the video:

This video covers concepts like thread safety, conditional thread safety, and reentrancy. We discuss the differences between these terms, the vital role that documentation plays in designing thread safe code, and how to effectively and clearly communicate the level of thread safety a particular function provides.

Please take a look and remember to subscribe!

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.

Results summary: C++ Foundation Developer Survey “Lite”, 2018-08: C++ and Cloud

Over the past week, we ran our second global C++ developer survey, this time focusing on C++ use in cloud-related workloads.

Thank you to everyone who responded. As promised, here is a public summary of the results:

CppDevSurvey-2018-08-cloud-summary.pdf

This summary has now been forwarded to the C++ standards committee, along with the full text of your write-in answers. Your feedback will be very helpful, and thank you again for your participation!

CppCon 2017: My Little Object File: How Linkers Implement C++—Michael Spencer

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:

My Little Object File: How Linkers Implement C++

by Michael Spencer

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Ever wonder how the linker turns your compiled C++ code into an executable file? Why the One Definition Rule exists? Or why your debug builds are so large? In this talk we'll take a deep dive and follow the story of our three adventurers, ELF, MachO, and COFF as they make their way out of Objectville carrying C++ translation units on their backs as they venture to become executables. We'll see as they make their way through the tangled forests of name mangling, climb the cliffs of thread local storage, and wade through the bogs of debug info. We'll see how they mostly follow the same path, but each approach the journey in their own way.

We'll also see that becoming an executable is not quite the end of their journey, as the dynamic linker awaits to bring them to yet a higher plane of existence as complete C++ programs running on a machine.