community

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

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.

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.

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.

CppCon 2017: Enough x86 Assembly to Be Dangerous—Charles Bailey

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:

Enough x86 Assembly to Be Dangerous

by Charles Bailey

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

This tutorial is an introduction to x86 assembly language aimed at C++ programmers of all levels who are interested in what the compiler does with their source code.

C++ is a programming language that cares about performance. As with any technology, a deep understanding of C++ is helped by knowledge of the layer below, and this means knowledge of assembly language. Knowing what the compiler does with your source code and the limitations under which it operates can inform how you design and write your C++.

We learn how to generate, inspect and interpret the assembly language for your C++ functions and programs. We take a short tour of common assembly instructions and constructs, and discover why extreme caution should be exercised if we are trying to infer performance characteristics from a simple inspection of assembly code.

Starting with a simple `operator+` for a user-defined class, we take a look at how interface and implementation choices affect the generated assembly code and observe the effect of copy elisions and related optimizations that compilers commonly perform.

CppCon 2017: How to Write Effective Documentation for C++ Libraries…—Robert Ramey

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 Effective Documentation for C++ Libraries...

by Robert Ramey

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

With the success of GitHub, everybody and his brother is a library developer. Programmers love to create code, upload it to GitHub and hope for immortality. Most projects get only the most cursory examination before being passed over by users. Why is that? GitHub considered the problem.

GitHub just published its 2017 Open Source Survey. The popular social coding service surveyed over 5,500 members of its community, from over 3,800 projects on github.com. It also spoke to 500 coders working on projects from outside the GitHub ecosystem. The Open Source Survey asked a broad array of questions. One that caught my eye was about problems people encounter when working with, or contributing to, open source projects. An incredible 93 percent of people reported being frustrated with “incomplete or confusing documentation”. see https://thenextweb.com/dd/2017/06/02/...

Even the most experienced and dedicated software developers can't do it. This can be confirmed by looking over recent reviews of Boost libraries. The most common complaint is that the documentation isn't useable.

Programmers love their stuff and hope to get people to use it, why don't they fix their documentation? The reason is simple: They don't know how.

Problems

a) It's tedious and boring to write
b) Developers don't know what to include and what to exclude
c) Tools make things harder
d) Regardless of the amount of effort invested, the end result is usually of little or no value.

This presentation will present a "Cookbook" and demonstration for creating documentation. Using this method will

a) Much diminish the tedium of the task.
b) Help improve to the quality of library design and implementation
c) Create something that is useful to the library user.

We will touch upon tools like Doxygen, etc. But this is only a small portion of the presentation. We use them so they deserve mention. But they don't cause the problem, and they don't solve it either.