Comment Feed for Channel 9 - C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11

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

Ben Hanson — Tue, 04 Oct 2011 18:30:14 GMT

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

posted by Ben Hanson

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

vesuvius — Tue, 04 Oct 2011 21:36:30 GMT

Its good to have broadband again

posted by vesuvius

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

new2STL — Tue, 04 Oct 2011 22:12:44 GMT

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

posted by new2STL

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

Philhippus — Wed, 05 Oct 2011 20:16:09 GMT

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

posted by Philhippus

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

Kometes — Wed, 05 Oct 2011 21:56:38 GMT

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

posted by Kometes

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

new2STL — Wed, 05 Oct 2011 22:31:14 GMT

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

posted by new2STL

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

MichaelPrice — Thu, 06 Oct 2011 15:57:54 GMT

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.posted by MichaelPrice

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

Garfield — Thu, 06 Oct 2011 17:03:34 GMT

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

posted by Garfield

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

Nathan Harvey — Thu, 06 Oct 2011 22:56:24 GMT

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

posted by Nathan Harvey

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

Waldemar Pawlaszek — Fri, 07 Oct 2011 08:14:27 GMT

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.

posted by Waldemar Pawlaszek

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

MichaelPrice — Fri, 07 Oct 2011 15:53:33 GMT

@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 
static shared_ptr make_shared (Params && ... params)
{
    // call to std::make_shared here...
}

posted by MichaelPrice

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

Alexander — Fri, 07 Oct 2011 19:55:18 GMT

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

posted by Alexander

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

Benjamin Lindley — Fri, 07 Oct 2011 20:53:04 GMT

Modules please.

posted by Benjamin Lindley

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

Waldemar Pawlaszek — Mon, 10 Oct 2011 09:58:22 GMT

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.

posted by Waldemar Pawlaszek

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

LuisCM — Tue, 11 Oct 2011 19:20:59 GMT

Legal Andrei Alexandrescu, Scott Meyers and Herb Sutter!

posted by LuisCM

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

mcmcc — Mon, 17 Oct 2011 20:38:50 GMT

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

posted by mcmcc

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

andrei_alexandrescu — Fri, 21 Oct 2011 16:27:37 GMT

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

posted by andrei_alexandrescu

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

hsutter — Mon, 24 Oct 2011 22:24:03 GMT

@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* load_widgets() or load_widgets( vector& ). C++11 example: vector 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& ).

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

posted by hsutter

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

Mike Stoodley — Mon, 07 Nov 2011 11:18:47 GMT

Partial classes. They make code generation so much easier.

posted by Mike Stoodley

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

Charles — Tue, 15 Nov 2011 23:25:04 GMT

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

posted by Charles

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

Markus Klein — Fri, 25 Nov 2011 16:55:11 GMT

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

posted by Markus Klein

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

Adrian Bentley — Thu, 15 Dec 2011 21:32:18 GMT

Get Modules out asap!

posted by Adrian Bentley