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 continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.