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

C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11

58 minutes, 23 seconds


Right click “Save as…”

I was able to attend C++ and Beyond 2011 and it was a tremendous experience. The technical depth and C++ goodness was profound and lasted for 3 whole days (and two evenings). Thanks Andrei Alexandrescu, Scott Meyers and Herb Sutter for allowing me to crash your affair with my camera - which was perhaps too big and too advanced for the likes of me - still, I was abe to capture some great content like this panel on C++11 with Scott, Andrei and HerbGreat questions from attendees. Note that this is the first in a series of three panels from C++ and Beyond 2011 that will appear on C9 over the coming months.

Make sure to check out all the C&B 2011 content we're lucky enough to have stored on C9 Smiley

Enjoy! Learn!

Table of contents (click on the time code link to move the player to that point in time...):

[00:19] When should new C++11 features be adopted in production?
[09:28] C++11 Memory Model
[15:23] Which C++11 features remain broadly missing?
[16:25] When can we expect full C++11 conformance from the major compilers?
[19:45] -> Herb Sutter asks YOU a question (please answer on this thread): What do you want the standards committee to work on next? Should they immediately start work on new features? Should they take a break before new feature work?
[21:45] What about debugging, linking and tools - as it relates to C++11?
[23:56] What really happened to Concepts?
[29:07] Will existing code have to be changed just to compile with a new C++11 conforming compiler?
[29:38] Why was a seemlingly complicated feature (to implement) like variadic templates rolled out sooner than a seemingly simple feature like templated typedefs?
[32:42] What do you think we'll get wrong most often when using C++11 features?
[45:13] Return by ref or by value - is there a universal rule of thumb?
[48:32] Why don't lambdas have typedefs for argument types?
[53:02] How do you capture enclosing scope variables when using lambdas?


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • Ben HansonBen Hanson

    So judging from the variety of opinions shown, Scott has his work cut out writing his new Effective C++ book!

  • Vesuviusvesuvius Count Orlock

    Its good to have broadband again

  • new2STLnew2STL xkcd.com

    @Ben Hanson: people on his blog already suggested "Even More Effective C++"  Big Smile

  • PhilhippusPhilhippus

    Scott asked if Herb would have time to "fix lambda's". Are lambda's broken? Having been watching channel 9 I thought they were sliced_bread++ :P

  • In response to lambda arg types at 49:00, I don't think it would be too much to ask for something like function_arity<T> and function_arg<T, int> to get the number and type of arguments of any regular/member/bind/lambda function.  I've written such a meta function for regular/member, but it's not possible for bind/lambda.

  • new2STLnew2STL xkcd.com

    @Philhippus: C&B2011 take place before the finalizing of the standard, I think they are talking about what Stephan called lambdas v1.1 (in reference to some last minute revision on decltype), I'm not the right person to answer it anyway but hope helped.

  • , new2STL wrote

    @Philhippus: C&B2011 take place before the finalizing of the standard, I think they are talking about what Stephan called lambdas v1.1 (in reference to some last minute revision on decltype), I'm not the right person to answer it anyway but hope helped.

    While the standard had not been voted on at the point that C&B2011 took place (it was unanimously approved a few days later), it's content had been all but frozen since early summer, particularly the language surrounding lambdas.  Although I have yet to hear Scott's actual comment, my guess would be that he is ribbing Herb about the lack of "polymorphic lambdas"; the idea that lambdas should be able to infer the types of their parameters instead of being explicit in the lambda declaration.

  • GarfieldGarfield

    I think many people cringed hearing Andrei's insistence on universal passing parameters by reference instead of returning by value. He definitely knows the efforts of the standardization committee and compiler writers to enable RVO and move on return to make it a non-issue. I might have expected that kind of reasoning from a low level Facebook manager who doesn't know better, but not from somebody with Andrei's IQ. I'm glad Herb commented about it, otherwise a less experienced listeners might have gotten the wrong idea. For all interested, Dave Abrahams dissected this issue in his article "Want Speed? Pass by Value."(http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/)

  • Nathan HarveyNathan Harvey

    Concerning the question on what to concentrate on next: some mechanism to allow serialisation without duplication of layout. Of all the outstanding issues with clean design that exist, that is the primary first-order domain language issue today. It forces one to use an out-of-language code generation tool (or bad design practice like member list duplication) for: new TCP protocols for client/server or peer-to-peer communications, web services, file saving, USB communication, shared memory and other distributed message passing, and any other communication system where objects must leave the runtime type system of c++. We find it unacceptable to have to duplicate lifetime specification (using RAII instead), we would never duplicate functionality when refactoring can use a common function, we look for advanced metaprogramming idioms to remove the need to specify common composition mechanisms in reusable pattern code, and yet the fundamental language problem requiring serialisable objects to have to re-specify their member list to some serialisation mechanism has not been fixed yet? Even with the ability to iterate over tuples, member access must duplicate the layout information on access, and no other existing language mechanism appears to solve this extremely common design need. Something as simple as iterating over members (with proper access restrictions) would solve this, but there are a number of acceptable approaches to this that work around what is commonly an introspection solution (tuple construction using name tags, for instance).

  • Waldemar PawlaszekWaldemar Pawlaszek

    Before new features there should be done some work on annoyances in existing ones. My nominee could be unusefulness of make_shared factory as it can't create classes with non-public constructor. Some base class to inherit from with some befriending could do the trick but apparently none has decided to do something about it.

  • @Waldemar Pawlaszek: Isn't it the job of the class with the non-public constructor to define who it's friends are? If he would like for someone to be able to make shared_ptrs to him, then he can have make_shared be a friend function or he can just have a

    template <typename ... Params>
    static shared_ptr<Me> make_shared (Params && ... params)
        // call to std::make_shared here...

  • AlexanderAlexander

    >> What do you want the standards committee to work on next?

    The one thing that looks very very fuzzy now is exceptions specifications for functions and methods. So far any code that looks like below is compiled with now problems on various compilers:

    void foo1() throw()
    throw std::exception("oops");

    void foo2() throw(std::exception)
    throw std::string("oops");

    I suppose it would be more correct to make exceptions specifications as strict as possible - if a function is stated to don't throw any exceptions, do now allow it to get compiled, even if it calls any functions that are not marked with throw(), the same for throw(std::exception). And to in order tp get it work well with function pointers, exceptions specifications have to be a part of function type, kind of const-volatile-exception specifier.

  • Benjamin LindleyBenjamin Lindley

    Modules please.

  • Waldemar PawlaszekWaldemar Pawlaszek

    It is not possible that way. Standard does not specify which function should actually call the constructor and in current Microsoft implementation the constructor is called from some implementation specific class and not from make_shared function. Additionally befriending some global function opens a back door to call that function from outside of the class (and hence create the object and we don't want that). make_shared should be defined in such way that it should not be accessible from outside of the class that we need to instantiate - that's the idea of hiding the constructor.

  • LuisCMLuisCM

    Legal Andrei Alexandrescu, Scott Meyers and Herb Sutter!

  • mcmccmcmcc

    @Garfield: Andrei's argument (and it's a good one) is that if you're worried about efficiency and you need to pass around large objects (e.g. std::vector<>'s), the most efficient way is to pass the object by reference, allowing the caller to reuse an existing instance (thereby reusing memory already allocated) if available. It isn't that move isn't useful, it's just not useful in the way that people tend to assume.

    FWIW, as far as Dave Abrahams' post goes, Herb doesn't buy it either - his specific recommendation was to pass by const reference always. He didn't elaborate on the details.

  • Andrei Alexandrescuandrei_alex​andrescu Andrei Alexandrescu

    @Garfield: Thanks for your comment. I believe I've argued my point properly, and my understanding is that Herb agreed with it. As @mcmcc mentioned, it's all rooted in the inescapable reality that creating a new composite object is sometimes more expensive than modifying an existing object. This issue gets compounded by repeated execution. As an example, we all know we do good to repeatedly refill the "current line" when reading text from a large file, as opposed to creating a new string upon each read. Rvalue references repair what could be considered a large gratuitous waste - but they don't do miracles, and we shouldn't expect them to.

  • @Garfield, @Andrei: The issue isn't that simple. There are two primary forms of "out" parameters, and the confusion comes primarily from not recognizing they are different. (A return value can be thought of as a restricted version of one of the out parameter cases that makes the caller's syntax simpler by not forcing him to create a named object to pass in.)

    The two primary cases are:

    1. "Callee-allocated out" (aka "factory" etc.). The callee is expected to generate a result, and the memory that contains it, and hands both back to the caller. This is where return-by-value of a movable object is natural and should be the encouraged C++11 pattern (it sure beats the workarounds of C++98 to try to avoid the unnecessary copy by simulating a move, such as via heap alloc + indirection). C++98 example: vector<widget>* load_widgets() or load_widgets( vector<widget>& ). C++11 example: vector<widget> load_widgets().

    2. "Caller-allocated out" (aka "fill parameter" etc.), or "either-allocated out" (when used as an optimization of #1, in the style of realloc). The callee generates the result, but puts it in storage provided and managed by the caller, either always (caller-allocated out) or when possible (either-allocated out, and the caller's buffer is otherwise deallocated and replaced with a newly callee-allocated buffer). Example: load_widgets( vector<widget>& ).

    In both cases, the callee generates the value/object. However, they differ in who allocates and manages the memory for the result. (As is often the case, C++ lets us profitably and clearly distinguish between object lifetime/management and memory lifetime/management. This is just another example of that.)

    For #1, which is very common (e.g., nearly every factory or object producer), return by value of a movable object should definitely be the recommended C++11 style.

    I should probably write more GotWs now, and this is one of the first I've been considering...

  • Mike StoodleyMike Stoodley

    Partial classes. They make code generation so much easier.

  • CharlesCharles Welcome Change

    Taking C++ to 11. There's just no escaping Spinal Tap, is there? Smiley

  • Markus KleinMarkus Klein

    About what I'd like to see the Standard committee working on:
    I'd like to see a modul system for C++ as soon as possible. Other than that I think working on enhancing the standard library might prove more useful than adding new language features (although concepts would still be nice to have). I've got this areas in mind:
    Network Sockets and Protocols

  • Adrian BentleyAdrian Bentley

    Get Modules out asap!

Remove this comment

Remove this thread


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.