CppCon 2015

How do we use C++14 to make our code better, rather than just different? How do we do so on a grand scale, rather than just for exceptional programmers? We need guidelines to help us progress from older styles, such as “C with Classes”, C, “pure OO”, etc. We need articulated rules to save us from each having to discover them for ourselves. Ideally, they should be machine-checkable, yet adjustable to serve specific needs.

In this talk, I describe a style of guidelines that can be deployed to help most C++ programmers. There could not be a single complete set of rules for everybody, but we are developing a set of rules for most C++ use. This core can be augmented with rules for specific application domains such as embedded systems and systems with stringent security requirements. The rules are prescriptive rather than merely sets of prohibitions, and about much more than code layout. I describe what the rules currently cover (e.g., interfaces, functions, resource management, and pointers). I describe tools and a few simple classes that can be used to support the guidelines.

The core guidelines and a guideline support library reference implementation will be open source projects freely available on all major platforms (initially, GCC, Clang, and Microsoft).

Use, comment, and contribute!

This talk will cover why engineers looking for performance choose C++. 

Jon will present an historical perspective of C++ focusing on what’s going on in the C++ community right now and where the language and its user base is heading.

With a renewed interest in performance for both data centers and mobile devices, and the success of open source software libraries, C++ is back and it is hot. This talk will explain why C++ is most software engineers’ go-to language for performance.

You will receive a rough historical sketch that puts C++ in perspective and covers its popularity ups and downs.

This talk is based, in part, on the book "C++ Today: The Beast is Back" published by O'Reilly. 

Part I: Introduction to lock-free programming. We will cover the fundamentals of lock-free vs lock-based programming, explore the reasons to write lock-free programs as well as the reasons not to. We will learn, or be reminded, of the basic tools of lock-free programming and consider few simple examples. To make sure you stay on for part II, we will try something beyond the simple examples, for example, a lock-free list, just to see how insanely complex the problems can get. Part II: having been burned on the complexities of generic lock-free algorithms in part I, we take a more practical approach: assuming we are not all writing STL, what limitations can we really live with? Turns out that there are some inherent limitations imposed by the nature of the concurrent problem: is here really such a thing as “concurrent queue” (yes, sort of) and we can take advantages of these limitations (what an idea, concurrency actually makes something easier!) Then there are practical limitations that most application programmers can accept: is there really such a thing as a “lock-free queue” (may be, and you don’t need it). We will explore practical examples of (mostly) lock-free data structures, with actual implementations and performance measurements. Even if the specific limitations and simplifying assumptions used in this talk do not apply to your problem, the main idea to take away is how to find such assumptions and take advantage of them, because, chances are, you can use lock-free techniques and write code that works for you and is much simpler than what you learned before.

Part I: Introduction to lock-free programming. We will cover the fundamentals of lock-free vs lock-based programming, explore the reasons to write lock-free programs as well as the reasons not to. We will learn, or be reminded, of the basic tools of lock-free programming and consider few simple examples. To make sure you stay on for part II, we will try something beyond the simple examples, for example, a lock-free list, just to see how insanely complex the problems can get. Part II: having been burned on the complexities of generic lock-free algorithms in part I, we take a more practical approach: assuming we are not all writing STL, what limitations can we really live with? Turns out that there are some inherent limitations imposed by the nature of the concurrent problem: is here really such a thing as “concurrent queue” (yes, sort of) and we can take advantages of these limitations (what an idea, concurrency actually makes something easier!) Then there are practical limitations that most application programmers can accept: is there really such a thing as a “lock-free queue” (may be, and you don’t need it). We will explore practical examples of (mostly) lock-free data structures, with actual implementations and performance measurements. Even if the specific limitations and simplifying assumptions used in this talk do not apply to your problem, the main idea to take away is how to find such assumptions and take advantage of them, because, chances are, you can use lock-free techniques and write code that works for you and is much simpler than what you learned before.

Modern C++ is clean, safe, and fast. It continues to deliver better and simpler features than were previously available. How can we help most C++ programmers get the improved features by default, so that our code is better by upgrading to take full advantage of modern C++?

This talk continues from Bjarne Stroustrup’s Monday keynote to describe how the open C++ core guidelines project is the cornerstone of a broader effort to promote modern C++. Using the same cross-platform effort Stroustrup described, this talk shows how to enable programmers write production-quality C++ code that is, among other benefits, type-safe and memory-safe by default –  free of most classes of type errors, bounds errors, and leak/dangling errors – and still exemplary, efficient, and fully modern C++.

Background reading: Bjarne Stroustrup’s 2005 “SELL” paper, “A rationale for semantically enhanced library languages," is important background for this talk.

Open source software licenses are intended to provide a way for software authors to protect their own rights, and the rights of the users of their software, but many developers are unaware of how they work, why they are important, and how to apply them to their projects.

It may never have occurred to you, but software licenses are much like programs: they are developed to meet requirements, they live in a world of external influences and constraints, and they use documented techniques to solve problems.

In this session, the attendees will participate in a fun, interactive process to choose the components of a software license through real-world examples, with the goal of every attendee leaving with a basic understanding of the more important aspects of software licenses. Along the way they will learn the basics of copyrights and how they apply to software; what 'derivative work' and 'distribution' mean in these contexts; and many other useful concepts, including the most important differences between common licenses like the GNU General Public License family and the Apache 2 license.

A primary use case for C++ is low latency, low overhead, high performance code. But C++ does not give you these things for free, it gives you the tools to control these things and achieve them where needed. How do you realize this potential of the language? How do you tune your C++ code and achieve the necessary performance metrics?

This talk will walk through the process of tuning C++ code from benchmarking to performance analysis. It will focus on small scale performance problems ranging from loop kernels to data structures and algorithms. It will show you how to write benchmarks that effectively measure different aspects of performance even in the face of advanced compiler optimizations and bedeviling modern CPUs. It will also show how to analyze the performance of your benchmark, understand its behavior as well as the CPUs behavior, and use a wide array of tools available to isolate and pinpoint performance problems. The tools and some processor details will be Linux and x86 specific, but the techniques and concepts should be broadly applicable.

Range-based interfaces are functional and composable, and lead to code that is correct by construction. With concepts and ranges coming to the STL, big changes are in store for the Standard Library and for the style of idiomatic C++. The effort to redefine the Standard Library is picking up pace. Come hear about one potential future of the STL from one of the key people driving the change.