2:00pm

We will provide a brief overview including an explanation of what Unicode is, string terminology, and how Unicode supports non US languages.

We will cover the pros and cons of various String formats and encodings including UTF-8, UTF-16, UCS-4, etc. A time line of Unicode development will be shown and how other languages have handled string processing over the last twenty years.

We will provide a brief overview of where strings are used, what can go wrong with strings, why string encoding is important, and how the CsString library solves a major problem with string handling.

We will explain how the CsString library has changed our CopperSpice Gui libraries and improved string processing in DoxyPress.

I am an independent consultant with over twenty-five years of experience as a programmer and software developer. I have worked with numerous smaller companies developing in-house applications. I have also designed and developed Windows applications for several vertical markets including... Read More →

I have been working as a programmer for nearly twenty years. My degree is in Computer Science from Cal Poly San Luis Obispo. I have transitioned to independent consulting and I am currently working on a project for RealtyShares in San Francisco.
Co-founder of CopperSpice... Read More →

3:15pm

C++17 reserves the namespace std2 (and others) for future iterations of the standard library that may not be 100% compatible in design with the current namespace std. This session will suggest a much simpler allocator model that might be useful for that new library.

What is an allocator model, and why should we care? There are a variety of experiments and benchmarks around now demonstrating the benefits that a well-chosen allocator can bring to performance-sensitive code. We would like to bring those benefits to any new standard library, but without the complexity that plagues the specification of allocators in the current standard library. An allocator model is a set of rules for writing and supplying allocators to typed and objects, and the set of rules those types should follow when using a custom allocator. Following the principle that you should not pay for what you do not use, we will look into creating a model with minimal impact on code and complexity on users — in fact we will demonstrate (in theory) a model that will typically involve writing no code for users to support custom allocators in their type, and a runtime cost that can be entirely eliminated in programs that never choose a custom allocator!

This presentation is a thought experiment in a possible future direction, and still a year or so away from becoming a proposal for standardization — in particular it will rely on creating a new language feature that we should demonstrate in a practical compiler. It offers a vision of a possible future for the language, and some of the problems that we would like to solve.

Alisdair Meredith is a software developer at BloombergLP in New York, and the C++ Standard Committee Library Working Group chair.He has been an active member of the C++ committee for just over a decade, and by a lucky co-incidence his first meeting was the kick-off meeting for the... Read More →

4:45pm

Want to make fast linked lists? Want to store sensitive data in memory? Want to place std::unordered_map in thread-local memory? Shared memory? How about GPU memory? You can do that in today’s C++ with allocators, the secret components of every STL container. Allocators went through a quiet revolution in C++11 and a major expansion in C++17. What did that give us? We'll look at the allocators available today in C++17, boost, TBB, and other popular libraries, and demonstrate some of the amazing things that can be achieved by taking the step beyond the stack and the heap. This talk is not about allocator implementation, but is a showcase of the things that can be done with off-the-shelf allocators available now and with C++17.

4:45pm

We already have array, vector, and unordered_map, what other data structures could we possibly need?

As it turns out, there are a lot of them and they come from all areas of software! Curious to learn the latest method of representing a pathfinding search space in detailed 3D environments? Does efficiently detecting if a website could be malicious sound like an interesting problem to you? Perhaps understanding how AAA games store and track their entities so efficiently is more your speed?

All these things and more can be yours in exchange for just one hour of your time! Using that hour we will delve into some of the unique challenges faced by C++ developers in a variety of domains, and learn the inner workings of the creative solutions devised to solve them.

Allan Deutsch is a Program Manager at Microsoft working in the Advanced Technology Group. He is a BSCS graduate from DigiPen Institute of Technology, where he focused on game development and gained an interest in game engine design.

5:20pm

We have often found it limiting that std::function cannot store callable objects if they are not copyable, so we developed and open-sourced folly::Function, a function wrapper that can store move-only callable objects. This presentation outlines the design decisions behind folly::Function and illustrates their consequences and our experiences after 18 months of wide production use at Facebook.

We find folly::Function is more appropriate than std::function for typical use cases, such as storing callback functions and submitting tasks for asynchronous execution. Other features of folly::Function include that it is noexcept-movable, and it avoids some known issues regarding const-correctness in std::function, which allows to invoke non-const operations on a const reference. Instead, folly::Function lets you declare whether a callable may or may not mutate its state (e.g. folly::Function＜void() const＞).

2:00pm

Are allocators worth the trouble? What situations merit their use? How are they applied effectually? What’s the performance impact? This practical talk by large scale C++ expert Dr. John Lakos demonstrates that having allocators in your tool box may lead to orders of magnitude speed improvements.

The runtime implications of the physical location of allocated memory is often overlooked, even in the most performance critical code. In this talk, we will examine how the performance of systems can degrade when using `new`/`delete` and `std::allocator` . We will contrast these global allocators, which allocate memory globally for a system, with local allocators that each allocate memory for a proper subset of objects in the system. We will also demonstrate how local allocators can reduce or entirely prevent the degradation seen in systems that rely on the global allocator. Six dimensions – fragmentability, allocation density, variation, locality, utilization, and contention – will be introduced to depict the potential for performance penalties and aid the listener in determining which local allocator will offer the best performance in their subsystems. Evidence will be presented that identifying these dimensions, and selecting a local allocator based upon them, can lead to *order-of-magnitude* reductions in run time compared to systems using a global allocator.

John Lakos, author of Large-Scale C++ Software Design, serves at Bloomberg LP in New York City as a senior architect and mentor for C++ Software Development world-wide. He is also an active voting member of the C++ Standards Committee’s Evolution Working Group. Previously, Dr... Read More →

3:15pm

Are allocators worth the trouble? What situations merit their use? How are they applied effectually? What’s the performance impact? This practical talk by large scale C++ expert Dr. John Lakos demonstrates that having allocators in your tool box may lead to orders of magnitude speed improvements.

The runtime implications of the physical location of allocated memory is often overlooked, even in the most performance critical code. In this talk, we will examine how the performance of systems can degrade when using `new`/`delete` and `std::allocator` . We will contrast these global allocators, which allocate memory globally for a system, with local allocators that each allocate memory for a proper subset of objects in the system. We will also demonstrate how local allocators can reduce or entirely prevent the degradation seen in systems that rely on the global allocator. Six dimensions – fragmentability, allocation density, variation, locality, utilization, and contention – will be introduced to depict the potential for performance penalties and aid the listener in determining which local allocator will offer the best performance in their subsystems. Evidence will be presented that identifying these dimensions, and selecting a local allocator based upon them, can lead to *order-of-magnitude* reductions in run time compared to systems using a global allocator.

John Lakos, author of Large-Scale C++ Software Design, serves at Bloomberg LP in New York City as a senior architect and mentor for C++ Software Development world-wide. He is also an active voting member of the C++ Standards Committee’s Evolution Working Group. Previously, Dr... Read More →

4:45pm

Designing a fast IP stack from scratch is hard. Using delegates made it all easier for IncludeOS, the open source library operating system written from scratch in modern C++. Our header-only delegates are just as fast as C-style function pointers, compatible with std::function, and allows any object to delegate work to stateful member functions without knowing anything about the class they belong to. We use delegates for everything from routing packets to creating REST endpoints, and most importantly to tie the whole IP stack together. In this talk we’ll show you how we use delegates in IncludeOS, discuss pitfalls and alternatives, and give you all you need to get started.

Alfred Bratterud is the creator of IncludeOS, the C++ unikernel. The work on IncludeOS started as a PhD research project but has since evolved into a full time venture for the IncludeOS developer team. Alfred holds BSc and MSc in computer science from the University of Oslo, with... Read More →

4:45pm

Hash tables consume a large volume of both compute resources and memory across Google's production system. The design for hash tables in C++ traces its origins to the SGI STL implementation from 20 years ago. Over these years, computer architecture and performance has changed dramatically and we need to evolve this fundamental data structure to follow those changes. This talk describes the process of design and optimization that starts with std::unordered_map and ends with a new design we call "SwissTable", a 2-level N-way associative hash table. Our implementation of this new design gets 2-3x better performance with significant memory reductions (compared to unordered_map) and is being broadly deployed across Google.

Matt is a senior software engineer on the C++ libraries team at Google. Prior to Google he has worked on compilers, machine learning, and underwater robotics. In his free time, he scuba dives in warm places.

2:00pm

You'd like to improve the performance of your application with regard to memory management, and you believe this can be accomplished by writing a custom allocator. But where do you start? Modern C++ brings many improvements to the standard allocator model, but with those improvements come several issues that must be addressed when designing a new allocator.

This talk will provide guidance on how to write custom allocators for the C++14/C++17 standard containers. It will cover the requirements specified by the standard, and will describe the facilities provided by the standard to support the new allocator model and allocator-aware containers. We'll look at the issues of allocator identity and propagation, and examine their implications for standard library users, standard library implementers, and custom allocator implementers. We'll see how a container uses its allocator, including when and how a container's allocator instance propagates. This will give us the necessary background to describe allocators that implement unusual semantics, such as a stateful allocator type whose instances compare non-equal. Finally, the talk will provide some guidelines for how to specify a custom allocator's public interface based on the semantics it provides.

I've been working in C++ since discovering the second edition of The C++ Programming Language in a college bookstore in 1992. The majority of my career has been spent in medical imaging, where I led teams building applications for functional MRI and CT-based cardiac visualization... Read More →

4:45pm

The C++ elites have been talking for years about value semantics, immutability, and sharing by communicating. A better world without mutexes, races, observers, command patterns and so more lies ahead! When it comes to doing it in practice, it is not so easy. One of the main problem lies in our data structures...

Immutable data structures don't change their values. They are manipulated by producing new values. The old values remain there, and can be read safely from multiple threads without locks. They provide structural sharing, because new and old values can share common data — they are fast to compare and can keep a compact undo-history. As such, they are great for concurrent and interactive systems: they simplify the architecture of desktop software and allow servers to scale better. They are the secret sauce behind the success of Clojure and Scala, and even the JavaScript crowd is loving it via Facebook's Immutable.js.

We are presenting Immer, a C++ library implementing modern and efficient data immutable data structures.

In this session, we will talk about the architectural benefits of immutability and show how a very efficient yet powerful persistent vector type can be built using state of the art structures (Relaxed Radix Balanced Trees). We will also show an example application (a text-editor) built using the architectural style here proposed. Not only is its code extremely simple, it outperforms most similar programs. Don't believe it? Come and see!

Juanpe is a Berlin based freelance software engineer, with a focus on interactive software, modern C++, functional programming and open source strategy. Before he worked for Ableton and he has been involved in various music technology projects. He has also developed for the GNU project... Read More →

9:00am

Memory allocators have a bad rap. Sure, they give us control, sometimes vital control, over how and where memory is allocated, but they seem so hard to use correctly. The allocator model that was first standardized in C++98 was put in place to solve a different problem; despite being called "allocators," control over memory allocation was, at best, a secondary consideration. Changes in C++11 and C++17 corrected many of the flaws, at the cost of complexity in the specification. If only there were a user manual and tutorial for allocators, much of that complexity would fall away and could be ignored. This talk strives to be that user manual and tutorial, intended to focus your attention on the important parts of modern allocators, and leaving most of the legacy stuff from 1998 behind. We will look at the easiest way to design a class that uses allocators, and walk through the creation of a real, useful allocator. In the process, I will introduce features in C++17 that can easily be adapted for use with today's C++11 and C++14 standard libraries. My goal is to make allocators approachable, so that you can use them appropriately in your own work.

Pablo Halpern has been programming in C++ since 1989 and has been a member of the C++ Standards Committee since 2007. His major contributions to the standard have been in the areas of parallel and vector programming constructs as well as on improvements to the usability of memory... Read More →

9:00am

C++ has a handful of associative containers. We started with set and map, both based on node-based red-black trees. These are fine but are not the most efficient and, in particular, suffer from more cache misses than we’d like. If we want to build persistent versions of them it’s achievable but aggravates the problems even more and adds considerable extra complexity. (I know — I’ve done it!) C++11 brought the hash-map based unordered_set and unordered_map, which are generally much faster, with better cache locality — but can be less memory-efficient and also don’t translate so easily into persistent versions.

But there exists another general-purpose data structure that combines many of the characteristics of trees and hash tables into something that in many important ways is superior to both, and with minimal downside (they are close but not quite as fast as pure hash tables). Hash Array Mapped Tries are more memory-efficient than hash tables and, as a bonus, are trivially made persistent — with big implications for concurrency, functional programming, and other applications that benefit from being able to treat them immutably (as well as share large amounts of common state in memory at once). This talk will describe how this data structure works from the ground up and look at a reference implementation I am writing with the intention of proposing as a Boost library — and possibly later for standardisation. We’ll also look at how it can be used in practice, and at some of the performance characteristics.

Marshall has been programming professionally for 35 yearsHe is the author of Boost.Algorithm, and has been a contributor to Boost for more than 15 years. He is the chairman of the Library working group of the C++ standard committee. He is the lead developer for libc++, the C++ standard... Read More →