Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

An Effective C++11/14 Sampler

Download

Right click “Save as…”

Zip

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.

 

Follow the Discussion

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

  • 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

  • @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.

  • mmutzmmutz

    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?

  • 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.

  • Scott MeyersScott 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.

  • Scott MeyersScott 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.

  • Thanks for the prompt answer, Scott. Much appreciated.

  • JohnJohn

    @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

  • LinunixLinunix

    When could we have the slide ?

  • Scott MeyersScott Meyers

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

  • Scott MeyersScott 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.

  • JohnJohn

    @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.

  • Scott MeyersScott 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!

  • LinunixLinunix

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

  • 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.

  • Scott MeyersScott 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.

  • Mike PrikhodkoMike Prikhodko

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

  • Scott MeyersScott 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.

  • Mike PrikhodkoMike 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.

  • Scott MeyersScott 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.

  • 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?

  • Scott MeyersScott 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.

  • DarijoDarijo

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

  • Scott MeyersScott 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.

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

Remove this comment

Remove this thread

close

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.