Writing Good C++14... By Default

Sign in to queue


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.







Download this episode

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().

Add Your 2 Cents