Large-Scale Refactoring @ Google

by Hyrum Wright

(watch on YouTube) (watch on Channel 9)

Many organizations have significant investments in a large existing C++ codebase, and Google is no exception. Our code is intended to survive for decades, but continue to track new language standards as they emerge. To do so, we have developed tools and techniques which provide the ability to automatically refactor code to use new APIs as they become available.

In this talk, I'll discuss some of the reasons for doing migrations that impact hundreds of thousands of files, and how we do them at Google, using tools such as ClangMR. I'll give examples, such as our recent migration to the standardized std::unique_ptr and std::shared_ptr types and lessons we've learned from these experiences. Finally, I'll point out pitfalls others may face in doing similar work, and suggest ways that they can be avoided.

Defensive Programming Done Right, Part II

by John Lakos

(watch on YouTube) (watch on Channel 9)

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.

Defensive Programming Done Right, Part I

by John Lakos

(watch on YouTube) (watch on Channel 9)

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.

Lock-free by Example

by Tony Van Eerd

(watch on YouTube) (watch on Channel 9)

Dive into and follow along making a lock-free queue.

In particular, a multi-producer, multi-consumer, growing, shrinking, mostly contiguous, lock-free circular queue.

With this single (complicated!) example, we will come across, and attempt to solve, many of the typical problems found in lockfree programming, and delve into the pros and cons of various solutions to those problems.

Eggs.Variant - Part II (the constexpr experience)

by K-ballo

Ruminations on the development of Eggs.Variant, a C++11/14 generic, type-safe, discriminated union. Part I explored a straightforward implementation based on untyped raw storage appropriate to hold any of the variant members. It was noted, however, that such an implementation would never be constexpr-aware. It's time to throw it away and start from scratch in order to properly support constexpr...

Generic Programming with Concepts Lite, Part II

by Andrew Sutton

(watch on YouTube) (watch on Channel 9)

In this talk, I will give an overview of the Concepts Lite language extension for C++ and present examples of its use in design and implementation of real-world generic libraries. Concepts Lite provides the ability for programmers to directly state constraints on template arguments as part of the template declaration. These constraints are predicates which determine whether or not a template argument can be used with that template. Constraints are checked by the compiler at the point of use, meaning that that effectively constrained generic libraries will not suffer from the usual problems of insane diagnostics. Libraries written using concepts will be far more readable and maintainable than the status quo. This talk will focus on generic programming, proposed language features, and their use in building real-world libraries.

Concepts Lite is a forthcoming ISO Technical Specification (TS) aimed at publication alongside C++14. Concepts Lite is implemented in a branch of GCC, which will be made available to the audience for experiments and experience.

Generic Programming with Concepts Lite, Part I

by Andrew Sutton

(watch on YouTube) (watch on Channel 9)

In this talk, I will give an overview of the Concepts Lite language extension for C++ and present examples of its use in design and implementation of real-world generic libraries. Concepts Lite provides the ability for programmers to directly state constraints on template arguments as part of the template declaration. These constraints are predicates which determine whether or not a template argument can be used with that template. Constraints are checked by the compiler at the point of use, meaning that that effectively constrained generic libraries will not suffer from the usual problems of insane diagnostics. Libraries written using concepts will be far more readable and maintainable than the status quo. This talk will focus on generic programming, proposed language features, and their use in building real-world libraries.

Concepts Lite is a forthcoming ISO Technical Specification (TS) aimed at publication alongside C++14. Concepts Lite is implemented in a branch of GCC, which will be made available to the audience for experiments and experience.

Range comprehensions with C++ lazy generators

by Paolo Severini

Lazy evaluation is a powerful tool and a pillar of functional programming; it gives the ability to construct potentially infinite data structures, and increases the performance by avoiding needless calculations ...

... Functional languages like Haskell have the concept of list comprehensions ... In C#, of course, we have LINQ ... It would be nice to have something similar in an eager language like C++ ... now the lazy, resumable generators proposed by N4286 seem perfect for this purpose ... We can use the VS2015 CTP prototype to experiment with this idea ...

Iterators++, Part 3

by Eric Niebler

This is the forth and final post in a series about proxy iterators, the limitations of the existing STL iterator concept hierarchy, and what could be done about it. The first three posts describe the problems of proxy iterators, the way to swap and move their elements, and how to rigorously define what an Iterator is.

This time around I’ll be focusing on the final problem: how to properly constrain the higher-order algorithms so that they work with proxy iterators.

A conditional copy constructor

by Andrzej Krzemieński

In this post we will try to define a ‘wrapper’ class template that does or does not have a copy constructor depending on whether the wrapped class has it. This will be a good opportunity to explore in depth a couple of advanced C++ features. Note that this is a rather advanced topic and, unless you are writing or maintaining a generic library, you will probably never need this knowledge.