C++ and Beyond 2011: Benedict Gaster on C++11, C++ AMP, C++ Renaissance

Very Good interview. Its nice to get advanced C++ users point of view. I think you should do more of these types of interviews. The most advanced C++ users (aka language lawyers) live at http://groups.google.com/group/comp.lang.c++.moderated. Many of them have memorized the standard, and can recite it's verses on queue. a few of the gray beards there have written books on C++. Maybe you could convince some of them to do an interview (over phone if nothing else). Just a suggestion.

Cheers

Hi Charles, great video! It gives me ideas about more vidoes you could do too. Liking the momentum you have going now!

I am really enjoing these videos from the general public (if you can describe Ben as that). The questions were good and the conversation moved succinctly (maybe with a little editing help, thank you) but it kept the relaxed feel of just talking to the general public about what their frustrations and interests regarding C++, MS, etc. are.

I agree with Ben that a lot more needs to be done with C++ to make template meta programming cleaner with better syntax. Bjarne recently published C++15 (?) updates on his website regarding Concepts, etc. which kind of connects here. Maybe Bjarne might be willing to discuss that or any of his recent published material on C9. He could solicit some ideas of syntax help in return before it makes it into C++15!?

His new Concept updates and multimethod publications are particularly interesting. If you look carefully, the very remote possibility of a completely revised C++ synyax is also in evidence. Go fish for that!

Ben mentions Auto abuse. A lot of people worry with him. It is just readability though? What about "code mutation" where the rafactoring of the "right side" of an auto expression causes unexpected events on the many "left side" instances of the code? Is this a real concern?

Maybe a "preview article" from "C++11 coding standards" or "Effective C++11" could investigate?

Anyway, great video charles, and thanks to Ben for being brave enough to get on camera!

The concern with auto and lack of type info is a bit unfounded if you have a modern development environment. In VC10 for example, just hovering your mouse over a variable will tell you it's type, without compilation even needed.
Actually this is a similar argument to what was used to promote Hungarian notation - we must always know the exact type of a variable at a glance! In any case c++ types are usually complex and therefore are often obfuscated via typedefs or other methods, auto alleviates the need for such scaffolding and greatly removes clutter, allowing the actual code to show through better.

Another great video! Out of curiosity, is anyone on the .net teams (.net cf, coreclr, or clr) using amp to speed up jitted tpl/rx code? Or maybe the IE team using amp to speed up web workers based JavaScript code.

Thank you for another very interesting interview.

All this C++ content is good stuff Charles, it seemed like such a desirable conference to go to, I'm slightly envious:P.

@Ian: I disagree.  Example (please ignore the poor memory management in the example):

class Base
{
public:
    void X () { cout << "Base" << endl; }

protected:
    Base() { }
};

class Derived : public Base
{
public:
    Derived() { }

    void X () { cout << "Derived" << endl; } // Hides Base::X
};

 Base * getObject() { return new Derived; }
// Refactor ^ into V
//Derived * getObject() { return new Derived; }

int main ()
{
    auto aobj = getObject();
    aobj->X();

    Base * bobj = getObject();
    bobj->X();
}

By refactoring some code, you get very different behavior (perhaps unexpected) in the using code that uses 'auto'.

IMO, 'auto' usage is appropriate under two scenarios (particularly where the two scenarios overlap):

1) Extremely long type name that is not frequently used within a particular scope.  If you use the type more than once or twice, consider a typedef instead.  This should be a rare usage.

2) Code that is likely to survive a refactor, such as swapping out a std::list and a std::vector.

These two overlap iterating over a container, which *should* the the predominant usage of 'auto' (see range-based for-loop for an example).

I agree, the committee missed the opportunity to standardise polymorphic lambdas, but I didn't get his complaint about lambdas been anonymous, isn't it the whole point of lambdas? And after all if one wants to give it a name, he can always assign it:
<code>auto lambda = [](){};</code>
No overload though; maybe that was the issue.

One more thing about lambdas being anonymous, you can't call it recursively; if it had a name you could have written:

auto lambda = factorial[](unsigned n)->unsigned
{ n ? n * factorial(n - 1) : 1u; }

As an alternative they could have had special syntax to reffer to the closure object, for example:

auto lambda = [](unsigned n)->unsigned
{ n ? n * [](n - 1) : 1u; }

recursive lambdas in C++

http://blogs.msdn.com/b/vcblog/archive/2008/11/18/stupid-lambda-tricks.aspx

No, unfortunately lambdas cannot be recursive, but polymorphic functions can, so, assigning lambda to polymorphic function will do the trick, though this solution will be pretty inefficient.

Lately, all the "High Quality MP4" videos require me to advance the audio by 300ms to make the audio in sync.

Thanks Charles.

this C++ content is good stuff, very Good interview

No overload though; maybe that was the issue.

Right. If you take two function overloads:

void foo(std::function<void(int)>);

void foo(std::function<void(float)>);

And pass a lambda to them:

foo( [](float a){return a + 1.f;} );

It won't work because you can't overload on the lambda itself, and you can't overload on std::function because it needs to resolve the overload before it knows which std::function to try to construct from the lambda. The problem of course is that the type of the lambda is not the type of its bracket operator, which is what you really need in the above. You can do tricks like indirect through a function and grab the bracket operator type then use that (maybe via a fuction reference) for overloading but it's clumsy and doesn't then distinguish between lambdas and std::function very well because you can't do overload resolution between std::function and lambdas.

I don't really see auto as a problem either, though. It's no more of an issue than using short variable names. Either way you can lose too much information too quickly, and fixing that is the job of a coding standard.

great stuff,

just a nit pick but gpus do have alot more than 20 cores, just the last gen dual chip dx10 card in my box has 1800 cores