Writing Good C++14... By Default

Download this episode

Download Video


Presentation Slides, PDFs, Source Code and other presenter materials are available at:https://github.com/isocpp/CppCoreGuid...

Modern C++ is clean, safe, and fast. It continues to deliver better and simpler features than were previously available. How can we help most C++ programmers get the improved features by default, so that our code is better by upgrading to take full advantage of modern C++?

This talk continues from Bjarne Stroustrup's Monday keynote to describe how the open C++ core guidelines project is the cornerstone of a broader effort to promote modern C++. Using the same cross-platform effort Stroustrup described, this talk shows how to enable programmers write production-quality C++ code that is, among other benefits, type-safe and memory-safe by default – free of most classes of type errors, bounds errors, and leak/dangling errors – and still exemplary, efficient, and fully modern C++.

Background reading: Bjarne Stroustrup's 2005 "SELL" paper, "A rationale for semantically enhanced library languages," is important background for this talk.







Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image

      I can't understand the example about shared_ptr (slide precisely at 1:00:00).
      Here's what Herb claims there:

      void f(int* p) { /* might invalidate p */ };
      shared_ptr<int> global_sp = make_shared<int>();
      int main() {
      f(global_sp.get()); // bad, and tool confirms it
      auto local_sp = global_sp;
      f(local_sp.get()); // OK, checker tool also has no complaints.
      return 0;

      I don't see why second case is a "good weather" scenario.
      When the statement "local_sp = global_sp" is executed, there's still a single copy of data, which they both point to.
      Given that, if f does something like "void f(int* p) { delete p; }", then f(local_sp.get()) will invalidate both local_sp and global_sp, so the issue actually becomes even worse.

      Am I wrong anywhere in my deduction?

    • User profile image
      John Lysons

      Could it be that there is already a rule that we don't do raw deletes but can reset shared pointers.
      So the problem is if f does gsp.reset() or g dies parameter 1.reset().

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.