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

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

Its good to have broadband again

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

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.

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

17 hours ago, 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.

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

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

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

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

Modules please.

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.

Legal Andrei Alexandrescu, Scott Meyers and Herb Sutter!

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

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

Partial classes. They make code generation so much easier.

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:
XML
Network Sockets and Protocols

Get Modules out asap!