GoingNative 2012 Sessions (HD)

This talk will cover:Which key features in C++11 will most change the way you write code: the features that directly affect C++ style, coding idioms, and the guidance in pre-C++11 books and articles that most needs to be updated. Specific guidance on each of those key features: how each one changes your code; tips on using it well; and a pitfall or two to avoid (and how). Status update on C++11 adoption: how compilers, books, and programmers are doing, plus a few updates and projections. What's next for C++: what's top of mind for the near future of Standard C++, and why?

Were we to craft a Lenox Globe of programming languages, C++ might be followed by a famous cautionary phrase: Here Be Dragons. The language can be complex and daunting to programmers who are often shouldered with the task of writing large, complex programs. Those millions of code monkeys need help to resist Murphy's siren song and navigate C++'s treacherous waters of memory corruption and concurrency bugs. Clang is a C++ compiler platform that tries to address these challenges (among others) across the spectrum of development activities. It provides fantastic diagnostics, static and dynamic program analysis, advanced rewriting and refactoring functionality, and language extensibility. Together with improvements to the language in C++11 these help programmers cope with today's code and write better code tomorrow. Clang also makes it easier than ever before to evolve and evaluate new language features and extensions to make C++ itself better. Through this talk I'll give some background on the Clang compiler, what it does today to make writing C++ better, and how we're using it to help shape the C++ language going forward.

To end the event, why not have all the speakers on stage to answer any questions you may have, ones that formed as your mind was bent over the last 48 hours. Here are some C++ titans in front of you - what are you going to ask them? What do you want to know? Ask the GoingNative 2012 speakers anything (within reason and subject to destruction by the moderator ). There should be lots to talk about. Don't be shy!This is an interactive panel. This means you, the attendee in the room or online, will be first class members of the conversation - you drive it. You ask the questions. The theme has been provided. Where do you want to take it? It's up to you.

C++ does not provide facilities for directly expressing what a function template requires of its set of parameters. This is a problem that manifests itself as poor error messages, obscure bugs, lack of proper overloading, poor specification of interfaces, and maintenance problems.Many have tried to remedy this (in many languages) by adding sets of requirements, commonly known as "concepts." Many of these efforts, notably the C++0x concept design, have run into trouble by focusing on the design of language features.This talk presents the results of an effort to first focus on the design of concepts and their use; Only secondarily, we look at the design of language features to support the resulting concepts. We describe the problem, our approach to a solution, give examples of concepts for the STL algorithms and containers, and finally show an initial design of language features. We also show how we use a library implementation to test our design.So far, this effort has involved more than a dozen people, including the father of the STL, Alex Stepanov, but we still consider it research in progress rather than a final design. This design has far fewer concepts than the C++0x design and far simpler language support. The design is mathematically well founded and contains extensive semantic specifications (axioms).

All right, the C++11 Standard is done. Can we go home? Definitely not - progress waits for no one.For all its might, C++11 is not addressing a few basic needs in template programming. For example, you'd hate to have to define a new function or indeed a whole new class wherever you need an "if" statement; yet, this is exactly what we do for template code. Also, conditional overloading using the likes of std::enable_if is syntactically bulky and semantically ham-fisted (as is visible with constructors and other special functions).This talk describes a new proposal (joint work with Herb Sutter and Walter Bright): a "static if" construct that works much like "if", just during compilation. It's reminiscent of #if, just done copiously right.With "static if" a lot of generic code becomes radically simpler, which in turn enables idioms that today are too complex to be usable. This proposal for C++ benefits from a large body of experience within the D programming language.

In 2011, we saw a resurgence of interest in native code - in C++ in 2011 and in C++11. Is this "C++ Renaissance" a flash in the pan? Is it a long-term trend? This is an interactive panel. This means you, the attendee in the room or online, will be first class members of the conversation - you drive it. You ask the questions. The theme has been provided. Where do you want to take it? It's up to you.

The C++ Standard Library expanded and evolved massively between C++98/03 and C++11.  It's easy to forget the magnitude of these changes, because they happened gradually and sometimes invisibly.  Some things (like shared_ptr, regex, and function) were developed in Boost in the early 2000s, before making their way into TR1 in 2005 and then C++11.  Other things, like container move semantics, automatically improve programs without human intervention.  Sometimes I can hardly believe that programmers used to live without non-intrusive deterministically reference-counted smart pointers!  We are fortunate to live in such an advanced and enlightened age.In this presentation, I'll explore how some of the C++11 Standard Library's magic works, including how the Standardization Committee fixed pair's constructors (I bet you think that pair is the simplest type in the world - ha! wrong!) and how I saved a million zillion bytes of memory across all the programs using VC10+'s make_shared<T>().Oh, and I will also reveal a secret that has never been announced before.

Variadic templates are arguably the most profound change in the core language brought about by C++11. Curiously, however, the C++ community still tiptoes carefully around them: variadic templates enjoyed less coverage than features such as "auto" or lambdas. Part of the reason is that more popular features simplify expression of existing designs, which makes said features easier to understand and use.Variadic templates, however, not only simplify design and use of advanced libraries such as Boost MPL, but also enable a host of new uses.This talk provides a solid coverage of variadic fundamentals, including typelists, the archetypal "safe printf" mechanics, and tuple construction and access. It also discusses more advanced uses, such as structured argument lists.

The C++11 standard introduces threads into the language, and carefully defines the meaning of variables shared between threads. The design is based on the idea that meaningful multithreaded programs should, by default, behave as though threads were executed in simple interleaved fashion. This allows efficient execution only because "data races" (simultaneous non-read-only accesses to shared variables) are disallowed.  Although this basic approach is shared with some other languages, and with threads interfaces like pthreads, we tried hard to avoid their mistakes.  For example, C++11 provides a comprehensive atomic operations library, which makes it much more feasible to avoid data races in real low-level code.I'll give a very quick overview of thread support in C++11, and then focus on the behavior of shared variables, often called the "memory model". I'll try to explain why, after more than 40 years of programming with shared variables, shared variables and atomic operations were still controversial, and why the C++11 approach is the right one.

We know how to write bad code: litter our programs with casts, macros, pointers, naked new and deletes, and complicated control structures. Alternatively (or additionally), we could obscure every design decision in a mess of deeply nested abstractions using the latest object-oriented programming and generic programming tricks. Then, for good measure, we might complicate our algorithms with interesting special cases. Such code is incomprehensible, unmaintainable, usually inefficient, and not uncommon.But how do we write good code? What principles, techniques, and idioms can we exploit to make it easier to produce quality code? In this presentation, I make an argument for type-rich interfaces, compact data structures, integrated resource management and error handling, and highly-structured algorithmic code. I illustrate my ideas and guidelines with a few idiomatic code examples.I use C++11 freely. Examples include auto, general constant expressions, uniform initialization, type aliases, type safe threading, and user-defined literals. C++11 features are only just starting to appear in production compilers, so some of my suggestions are conjecture. Developing a "modern style," however, is essential if we don't want to maintain newly-written 1970s and 1980s style code in 2020.This presentation reflects my thoughts on what "Modern C++" should mean in the 2010s: a language for programming based on light-weight abstraction with direct and efficient mapping to hardware, suitable for infrastructure code.