An Effective C++11/14 Sampler

Download this episode

Download Video

Description

After years of intensive study (first of C++0x, then of C++11, and most recently of C++14), Scott thinks he finally has a clue. About the effective use of C++11, that is (including C++14 revisions). At last year’s Going Native, Herb Sutter predicted that Scott would produce a new version of Effective C++ in the 2013-14 time frame, and Scott’s working on proving him almost right. Rather than revise Effective C++, Scott decided to write a new book that focuses exclusively on C++11/14: on the things the experts almost always do (or almost always avoid doing) to produce clear, efficient, effective code. In this presentation, Scott will present a taste of the Items he expects to include in Effective C++11/14. If all goes as planned, he’ll also solicit your help in choosing a cover for the book.

 

Download:

Zip

Day:

2

Code:

008

Embed

Format

Available formats for this video:

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

    The Discussion

    • User profile image
      ZF12

      Scott: "The question was 'blah blah blah', the answer was 'blah blah blah'. End result: nothing changed" Big Smile Loving it.

    • User profile image
      vittoriorom​eo

      I love this talk. Scott's topics are very interesting and he's just very funny! Can't wait to get Effective C++ Big Smile

    • User profile image
      ArashPartow

      @Scott: With regards to the question from 41:30;

      A simple G^MBing for the phrases:

      "win32 clang" or
      "ishani clang"

      will have what you're looking for.

       

      Too bad I can't paste the actual urls due to the asinine MS spam detection system.

    • User profile image
      mmutz

      Regarding the move from const gotcha: wouldn't something like the following work?

      template <typename T> ... std::move(const T &) = delete;

      or a

      static_assert( !is_const_t<T>, "Effective C++11, Item NN" );

      inside std::move?

    • User profile image
      Garp

      At around 1:10:00, there was a question about the ThreadRAII class (in the context of making sure that a std::thread is unjoinable on all paths).

      In the destructor,

      ~ThreadRAII() { if (t.joinable()) (t.*action)(); }

      someone asked Scott what would happen if t becomes unjoinable between the calls to t.joinable() and either t.join() or t.detach().

      I don't know if the answer is known yet but when it is, could it be posted here?

      Thanks.

    • User profile image
      Scott Meyers

      @Garp: The code is correct as written. The joinability of a std::thread object can be changed only by calling a std::thread member function, so if we're executing inside the destructor for a std::thread object, either we're the only member function running on that object (in which case the joinability of the object can't change asynchronously) or there's another thread executing code on the same object (in which case we have a race condition in our code, and behavior is undefined). In particular, the joinability of a std::thread object doesn't change just because the OS thread it corresponds to runs to completion.

      I knew this when I wrote the code, but I forgot it during the presentation, and I apologize for that. I delivered a revised version of the materials to GoingNative that spells this out, and I expect them to make these materials available for download.

    • User profile image
      Scott Meyers

      @mmutz: When writing generic code, you may not know whether you're dealing with a const object, so having it be an error to try to move a const rvalue (or even to cast a const object to be an rvalue) would complicate life for library writers. In a discussion with a couple of attendees after my talk, stl explained how a library writer might end up with a std::pair object, where one component was non-const (hence a good candidate for moving), while the other component was const (hence ineligible for moving). If it were an error to try move a const object (or to cast a const object to an rvalue), the library implementer would have to go through a lot of work that is currently unnecessary. (This can be generalized to even more work by considering a std::tuple with one or more const components.)

      The point I was trying to make in my talk was that std::move and std::forward don't move or forward anything. They simply perform casts. What happens after that depends on the type (including rvalueness/lvalueness) that results from the cast, and if the type includes const, that will inhibit moving.

    • User profile image
      Garp

      Thanks for the prompt answer, Scott. Much appreciated.

    • User profile image
      John

      @Scott:
      Great talk!
      It would be interesting to know how many of these new features would stand in a mission-critical environment. For example, given the MISRA suggestions, how much of this template code could be used for a real-time system?

      Thanks

    • User profile image
      Linunix

      When could we have the slide ?

    • User profile image
      Scott Meyers

      @Linunix: I sent my materials to the conference organizers several days ago, so I assume they'll be posted soon.

    • User profile image
      Scott Meyers

      @John: There is no real tension between templates and real-time systems. The general analysis approach is to treat each template instantiation as a separate function, then do the usual timing analysis on it. As for using C++11 features in mission-critical environments, I suspect that virtually all new features eventually will be, though I'd expect adoption of some of them to be comparatively slow, because developers of such systems will be conservative in their adoption. On the other hand, I'd expect such developers to quickly embrace the idea of using an RAII class to avoid having terminate called from a std::thread destructor.

    • User profile image
      John

      @Scott:
      Thanks! Your views are always of importance. :)
      It would be awesome if you could some day give a talk on mission-critical environments. There are many people in this area who would be willing to listen to your (master) views.

    • User profile image
      Scott Meyers

      @ArashPartow: I remain unable to find a way to run Clang from the command line on Windows. The binaries at ishani.org don't seem to have any content (it's a mostly-empty 7z file), and the installer from LLVM (http://llvm.org/builds/) gives me a compiler, but no information on how to configure it to find includes and libraries. If you know of a straightforward way to run Clang on Windows without having to build from source, please post!

    • User profile image
      Linunix

      Just good talk... i like your opinion and vision about the move semantic, i wait just your next talk ^^

    • User profile image
      NotFredSafe

      Scott, I love your books and your talks and your hair and all, but I think during this talk, you went a little bit overboard with the condescending remarks. "The question was bla bla bla", really?

      Looking forward to Effective C++11/14.

    • User profile image
      Scott Meyers

      @NotFredSafe: I'm sorry you didn't care for the "Blah blah blah" comment. As I recall (I haven't viewed the presentation online, so I'm going from memory here), the gist of the situation was that somebody asked a somewhat-complicated question, but then somebody else clarified the situation before I repeated the question, and the end result was that the question itself became irrelevant and, in my view, not worth repeating for the audience. So rather than paraphrase a question for everybody in the room that was no longer relevant, I said what I said. My intent wasn't to be condescending, it was to acknowledge that a question had been asked and to indicate that it wasn't worth taking the time to repeat.

    • User profile image
      Mike Prikhodko

      Why don't std::list member functions use conditional noexcepts like std::swap does?

    • User profile image
      Scott Meyers

      @Mike Prikhodko: A quick rundown of the container interfaces in the C++14 CD show that only the swap functions are declared conditionally noexcept using exception specifications. Other functions are essentially conditionally noexcept, though they don't use exception specifications to express that. For example, 23.2.5.1/1 says, "For unordered associative containers, ... erase(k) does not throw an exception unless that exception is thrown by the container’s Hash or Pred object (if any)." Why the Committee specified things in this way, I don't know.

    • User profile image
      Mike Prikhodko

      @Scott Meyers: Will noexcept(erase(k)) return 'true' if Hash and Pred objects are not throwing anything (and declaring this with 'noexcept')? If so, it's cool, but why do we need conditional noexcepts if compiler can deduce all information himself?

      If noexcept(erase(k)) always returns 'false'... It just looks like standard library is not good enough, because it doesn't use core language features consistently.

    • User profile image
      Scott Meyers

      @Mike Prikhodko: noexcept(erase(k)) will return true only if erase(k) is declared noexcept. The compiler never deduces exception specifications from the body of a function.

      I haven't take the time to check all the containers, but to the best of my knowledge, none of the erase functions are declared noexcept. Why they're not declared conditionally noexcept, I don't know.

    • User profile image
      Merick

      So if the C++ committee decided that always detaching or always joining was a bad idea, why is writing a RAII wrapper which always detaches or always joins safe?  Or under what conditions is always detaching or always joining the wrong answer?

    • User profile image
      Scott Meyers

      @Merick: The RAII wrapper I show doesn't automatically do anything. It does only what you expressly tell it to do. So if you decide that always joining (or always detaching) is safe for your code, you can use the wrapper to implement that logic. That's different from the standard library adopting a policy that would apply to everybody.

      For information on why detaching by default is problematic, consult the paper by Hans-J Boehm listed on slide 48 of the talk. The reason why always joining is problematic is that it can limit concurrency: the calling thread can't continue until the asynchronously running thread has completed. Hence the quote from the Standard I show on slide 38 in my talk.

    • User profile image
      Darijo

      Why not just: auto move(T&& param) instead of decltype(auto)?

    • User profile image
      Scott Meyers

      @Darijo: Type deduction using auto strips off references, and it's important that std::move return a reference. Hence the need for decltype(auto), which does not strip off references.

    • User profile image
      Marius Bancila

      Great talk. Looking forward to reading the (yet unwritten) book.

    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.