C++ and Beyond

This is a reminder that May marks the final month for early-bird registration for C&B.  Registrations that take place by the end of this month benefit from the 10% discount for individuals and 20% discount for groups of three or more.  If you’ve been procrastinating about getting authorization to attend or have been putting off the necessary paperwork, now would be a good time to tackle those tasks.  The early-bird period will not be extended, so you’ll want to get in under the May 31 deadline if you possibly can.  Or you can wait until afterwards and pay us more.  We’re happy either way :-)

Scott

PS – One of the benefits of choosing clipart to accompany posts is the odd things one finds in them.  In the image accompanying this post, I was amused to see that among the depicted currencies is German Marks, which have been out of circulation since 2002. The U.S. penny atop the stack of coins that is on top of the 100-Mark bill was last issued in 1958.

Writing code that is resilient upon errors (API failures, exceptions, invalid memory access, and more) has always been a pain point in all languages. This being still largely an unsolved (and actually rather loosely-defined) problem, C++11 makes no claim of having solved it. However, C++11 is a more expressive language, and as always more expressive features can be put to good use toward devising better error-safe idioms and libraries.

This talk is a thorough visit through error resilience and how to achieve it in C++11. After a working definition, we go through a number of approaches and techniques, starting from the simplest and going all the way to file systems, storage with different performance and error profiles (think HDD vs. RAID vs. Flash vs. NAS), and more. As always, scaling up from in-process to inter-process to cross-machine to cross-datacenter entails different notions of correctness and resilience and different ways of achieving such.

To quote a classic, “one more thing”! An old acquaintance—ScopeGuard—will be present, with the note that ScopeGuard11 is much better (and much faster) than its former self.

C++11 is kind of like “C++ Dreamliner.” It’s built with world-class modern materials. It took a couple more years to finish than originally expected. But now it’s starting to roll out worldwide and flying more safely and efficiently than ever. (European readers may equally consider it “C++ 380.”)

I write and teach, speaking about C++11 in particular:

“Modern C++ is clean, safe, and fast – modern C++ code is as readable and as type- and memory-safe as code written in any other modern language [*], and it has always been the king of ‘fast’ and is now faster than ever with new features like move semantics.” – Herb Sutter

Bjarne Stroustrup made me add, at the end of the “clean and safe” part:

“[*] When used in a modern style.” – Bjarne Stroustrup

Bjarne and I claim this to be true. Others have disputed various parts of this statement – whether C++11 really has a usable safe subset, whether C++ is really necessarily faster than code in other languages, and other questions. What’s the truth?

These answers matter. Type safety and memory safety are important not only for writing reliable code that will fail or be abused less often, but also for improving developer productivity so that developers can spend less time on overhead “taxes” like checking for unsafe casts or buffer overruns. And the claim that C++ really is the king of “fast” has been consistently challenged for most of its history.

In this panel, Scott, Andrei, and I will weigh in with discussion – and data – on these important and current questions.

In recent talks (e.g., at Going Native in February and at Lang.Next earlier this month), Herb has offered guidelines for proper usage of C++11.  He made it look so easy, I said to myself, “Heck, I could do that.”  Besides, people have been pestering me about a new edition of Effective C++, so I figured I’d sit down and try to come up with a few prospective guidelines.  “How hard can it be?,” I asked myself.

Easier than expected, actually.  In about a half hour, I’d jotted down some 25 candidate guidelines.  That’s more than enough for a meaty C&B talk, so I plan to give one.  What will be in the talk?  I don’t know yet, because what I have are prospective guidelines, and they will evolve as I work on them and as I learn more about C++11 and its effective application. (My knowledge continues to change almost daily.) What follows is a snapshot of the list of candidate guidelines I have right now.  The ordering is random, and the wording is tentative, so don’t read too much into them.  There are far more here than can be covered in single talk, so there’s no way I’ll cover all of these at C&B.  My plan is to focus on the ones I think include material that is particularly important or particularly surprising (e.g., counterintuitive). If you see a topic you’d like to hear about, please post a comment to that effect.  If you don’t see a topic you think I should address, please post about that.  If you see a guideline you think is bad advice, posting a comment is again the thing to do.  If you know of a good guideline you don’t see listed, post, post, post!

Scott

• Prefer auto to Explicit Type Declarations
• Distinguish () and {} When Creating Objects
• Remember that auto + { expr } == std::initializer_list
• Prefer non-member begin/end to member versions
• Declare std::thread Members Last in Classes
• Be Wary of Default Capture Modes in Lambdas Escaping Member Functions
• Prefer Emplacement to Insertion
• Pass std::launch::async if Asynchronicity is Essential
• Minimize use of Weak Atomics
• Distinguish Rvalue References from Universal References
• Assume that move operations are neither present nor cheap
• Prefer Lambdas over Binders
• Prefer Lambdas over Variadic Arguments to Threading Functions
• Be Wary of Oversubscription
• Apply std::forward when Passing Universal References
• Prefer std::array to Built-in Arrays
• Use std::make_shared Whenever Possible
• Prefer Pass-by-Reference-to-const to Pass-by-Value for std::shared_ptrs
• Pass by Value if You’ll Copy Your Parameter
• Reserve noexcept for Functions with Wide Interfaces
• For Copyable Types, View Move as an Optimization of Copy
• Prefer enum classes to enums
• Prefer nullptr to NULL and 0
• Distinguish among std::enable_if, static_assert, and =delete

If you’re reading this blog, it can be taken for granted that you think C++ is a commercially important programming language.  Today I came across Vincent Lextrait’s Programming Language Beacon, which summarizes the primary programming language used in nearly 100 major software products or utilities. I was not surprised that C++ was well-represented;  I was astonished at how well-represented it was!

Being an “anybody can publish anything on the Internet, so who knows if it’s true?” kind of guy, I did some cursory Googling for comments to the effect that Vincent Lextrait has no idea what he’s talking about.  I found none.  So I pinged Andrei and Herb to see if they knew about this table or could offer comments on its accuracy.  They had not seen it, either, but when they reviewed the data in the table, they found it accurate for all the products they were familiar with.

We believe that the table is legitimate, and if you have not seen it, we encourage you to take a look.  As I said, as a reader of this blog, you’re already a C++ believer, but this table may make you an even bigger believer, and it may also help you explain to others at least part of the reason why you are. Personally, my favorite part is where the table shows that Java’s JVM and .NET’s CLR are both written in C++, but that’s far from the only area where C++ trumps the competition.

At C++ and Beyond in August, Andrei and Herb and I will do our best to equip you with information that will  help you add to C++’s lead on a list that it already dominates.

Scott

PS – If you’re interested in other lists that demonstrate C++’s widespread commercial utilization, take a look at Bjarne’s C++ Applications page.

You can’t do a better job if you don’t change what you’re doing, but change is hard.  It’s especially hard when what needs to change is your colleagues’ approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they’re not doing, other times to stop doing something they’ve become accustomed to.  Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you’re proposing.  But how can you do that?

Like you, Herb and Andrei and I have co-workers we sometimes need to nudge in one direction or another, and as authors, trainers, and consultants, we often find ourselves needing to convince diverse sets of people we barely know to modify what they do.  In this panel session, the three of us share how we go about doing this, and, because specific examples are worth a thousand generalities, we take your questions, too.  In fact, we encourage you to post your “I just can’t get my colleagues to see the light!” stories, questions, and advice as comments on this blog post.

Scott

I plan to give a brand-new talk for the first time at C&B, but I’m conflicted regarding what to say about it here because it’s recently been a bit of a startling realization to me about C++11, and I think it may be a bit startling for others too. I don’t want to be a tease, but I also want to save it as a surprise for C&B itself.

In the meantime, here’s a teaser…

In addition to the many new C++11 features that everyone’s listing, it has dawned on me over the winter that there’s actually another major change that isn’t being talked about anywhere, or even being listed as a change in C++11 at all as far as I know, because I and other key experts and committee members I’ve asked didn’t fully realize that we altered the basic meaning of not one but two fundamental keywords in C++. It’s a change that has profound consequences, that rewrites and/or invalidates several pieces of pre-C++11 design guidance, and that’s directly related to writing solid code in a concurrent and parallel world. This isn’t just an academic change, either — everyone is going to have to learn and apply the new C++11 guidance that we’ll cover in this session.

I plan to talk about it first at C&B, in a session tentatively titled as above — I’ll fill in the keywords later. You may already guess a few keyword candidates based on the description above, and here’s a final hint: You’ll hardly find two C++ keywords that are older, or whose meanings are more changed from C++98 to C++11. (No, they aren’t auto and register.)

Herb

As Herb and Andrei and I determine the topics we’ll address in our technical sessions at C&B 2012, we’ll post them here. We’ll also post topics we may discuss–prospective sessions. In both cases, we welcome your feedback. What follows is the first session announcement for C++ and Beyond 2012.

Universal References in C++11
T&& Doesn’t Always Mean Rvalue Reference

Perhaps the most significant new feature in C++11 is rvalue references; they’re the foundation on which move semantics and perfect forwarding are built. An rvalue reference is declared like a “normal” reference (now known as an lvalue reference), except you use two ampersands instead of one, i.e., “T&&” instead of “T&”. A reasonable expectation would be that if you see a type declaration involving “&&”, you’re looking at an rvalue reference, but that’s not the case:

  int&& var1 = 10;                  // here, “&&” means rvalue reference

  auto&& var2 = var1;               // here, “&&” does not mean
                                    // rvalue reference 

  template<typename T>
  void f(std::vector<T>&& param);   // here, “&&” means rvalue reference 

  template<typename T>
  void f(T&& param);                // here, “&&” might mean
                                    // rvalue reference

In this talk, I describe the two meanings of “&&” in type declarations, explain how to tell them apart, and introduce new terminology that makes it possible to unambiguously communicate which meaning of “&&” is intended. Distinguishing the different meanings is important, because if you think “rvalue reference” when you see “&&” in a type declaration, you’ll misread a lot of C++11 code.

Our journey through DoubleAmpersandVille will include some interesting sights, including glimpses of the three different sets of type deductions rules in C++11, why “const T&&” does far more than just add const to “T&&”, how the token sequence “T&&” (where T is a template type parameter) can have completely different meanings in different function templates, and what decltype has in common with auto and templates. It’ll be a fun, illuminating ride, and by the time it’s over, you’ll be able to distinguish rvalue references from their syntactic twins with aplomb.

Scott

Now that registration for C++ and Beyond 2012 has begun, we’ll be making blog posts with increasing frequency to keep you apprised of developments related to the event. Among the most important posts will be those announcing topics for our technical sessions. Those posts will start later this week. (Because we typically develop all-new presentations for C++ and Beyond, we’re not in a position to announce the topics many months in advance. Instead, we let you know about them as we come up with them. In some cases, we’ll post about prospective sessions, and we’ll ask for feedback about how useful you think such sessions would be.)

Conceptually, we assume that people interested in C&B-related developments subscribe to the RSS feed for this blog. In reality, we know that blogs and RSS feeds are not everybody’s preferred mechanism for consuming information. As a result, our blog posts are automatically reflected to our twitter stream, our facebook page, and our mailing list. Practically speaking, we use the C&B blog as stdout for what we have to say, but we pipe that to other streams that may be more convenient for you. If you think we should pipe our posts elsewhere (other than to /dev/null, ahem), let us know.

Links to our RSS feeds, our twitter stream, our facebook presence, and our mailing list are in the sidebar on the right at the C++ and Beyond web site. They’re also embedded in the paragraph above.

Scott

We’re trying out some new blog plumbing, sorry, and sometimes the plumbing has to be tested.  This is one such case.

I apologize for the noise.

Scott