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

Play C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11
Sign in to queue


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?



Download this episode

The Discussion

  • User profile image
    Ben Hanson

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

  • User profile image

    Its good to have broadband again

  • User profile image

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

  • User profile image

    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

  • User profile image

    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.

  • User profile image

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

  • User profile image

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

  • User profile image

    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/)

  • User profile image
    Nathan 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).

  • User profile image
    Waldemar 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.

  • User profile image

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

  • User profile image

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

  • User profile image
    Benjamin Lindley

    Modules please.

  • User profile image
    Waldemar 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.

  • User profile image

    Legal Andrei Alexandrescu, Scott Meyers and Herb Sutter!

  • User profile image

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

  • User profile image

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

  • User profile image

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

  • User profile image
    Mike Stoodley

    Partial classes. They make code generation so much easier.

  • User profile image

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

  • User profile image
    Markus 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

  • User profile image
    Adrian Bentley

    Get Modules out asap!

Add Your 2 Cents