advanced

CppCon 2014 Multiplatform C++--Edouard Alligand

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Multiplatform C++

by Edouard Alligand

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++ is a multiplatform language, yet many difficulties arise when you want the same code to compile properly and function identically on different platforms. If you put aside the obvious system programming related obstacles, and the differences you might have between compilers (especially when it comes to supporting C++11 and C++14), you come to the surprising conclusion that what is truly hard is all the "little things" you didn't anticipate.

This talk will be about our experience with our own software, quasardb, that runs every day on three OS (FreeBSD, Linux and Windows), is built with three compilers (clang, gcc and msvc) and supports two architectures (IA32 and AMD64).

How to build natively the same software on Windows and Linux, provided that they have radically different tool chains? How to work around the subtle, but existing differences between Linux and FreeBSD? How do you solve cross-tools, cross-platform file editing problems? How to prevent your maintenance costs from increasing dramatically?

Safety: off - How not to shoot yourself in the foot with C++ atomics -- Anthony Williams

Guidelines for how to use C++ atomics safely in our code using worked examples.

Slides and code and for my ACCU 2015 presentation

by Anthony Williams

From the article:

It's now two months since the ACCU 2015 conference in Bristol, UK, so I thought it was about time I posted my slides.

This year my presentation was titled "Safety: off - How not to shoot yourself in the foot with C++ atomics". I gave a brief introduction to the C++ atomics facilities, some worked examples of usage, and guidelines for how to use atomics safely in your code.

The slides are available here, and the code examples here.

Standardizing Variant: Difficult Decisions -- Anthony Williams

Techincal discussion information while standardizing N4542.

Standardizing Variant: Difficult Decisions

by Anthony Williams

From the article:

One of the papers proposed for the next version of the C++ Standard is N4542: Variant: a type safe union (v4). As you might guess from the (v4) in the title, this paper has been discussed several times by the committee, and revised in the light of discussions.

Boost has had a variant type for a long time, so it only seems natural to standardize it. However, there are a couple of design decisions made for boost::variant which members of the committee were uncomfortable with, so the current paper has a couple of differences from boost::variant. The most notable of these is that boost::variant has a "never empty" guarantee, whereas N4542 proposes a variant that can be empty.

Simple C++11 metaprogramming--Peter Dimov

If you like to play with templates, read this article:

Simple C++11 metaprogramming

by Peter Dimov

From the article:

The wide acceptance of Boost.MPL made C++ metaprogramming seem a solved problem. Perhaps MPL wasn't ideal, but it was good enough to the point that there wasn't really a need to seek or produce alternatives.

C++11 changed the playing field. The addition of variadic templates with their associated parameter packs added a compile-time list of types structure directly into the language...

Holier Than Thou--Tony “Bulldozer00” (BD00) DaSilva

A rare but possible problem that can occur with long running programs:

Holier Than Thou

by Tony DaSilva

From the article:

Since C++ (by deliberate design) does not include a native garbage collector or memory compactor, programs that perform dynamic memory allocation and de-allocation (via explicit or implicit use of the “new” and “delete” operators) cause small “holes” to accumulate in the free store over time. I guess you can say that C++ is “holier than thou“. :( ...

How to implement a stateful meta-container in C++ -- Filip Roséen

Implementing stateful meta contianer in C++ Using Modern C++.

How to implement a stateful meta-container in C++

by Filip Roséen

From the article:

This post has explained the technical aspects related to an implementation of a stateful meta-container, allowing a developer to more easily work with, and modify, a given set of entities during the phase of translation.

Together with the previous posts in this series, the formerly unstateful world of translation has gone into a stateful universe — allowing for some crazy, but conforming, implementations.

CppCon 2014 Sanitize your C++ code--Kostya Serebryany

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Sanitize your C++ code

by Kostya Serebryany

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

"Sanitizers" is a family of dynamic testing tools built into C++ compilers (Clang and GCC):
AddressSanitizer finds memory errors, such as use-after-free, buffer overflows, and leaks;
ThreadSanitizer finds data races, deadlocks, and other threading bugs;
MemorySanitizer finds uses of uninitialized memory;
UndefinedBehaviorSanitizer finds other kinds of undefined behavior, such as use of incorrect dynamic type, shift by illegal amount and many others.
You will learn how these tools work, how to use them on small programs and how we deploy them in large projects.

CppCon 2014 Large-Scale Refactoring @ Google--Hyrum Wright

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Large-Scale Refactoring @ Google

by Hyrum Wright

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

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.

CppCon 2014 Defensive Programming Done Right, Part II--John Lakos

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Defensive Programming Done Right, Part II

by John Lakos

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

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.