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.