Comments

Thanks for watching, everyone. I'm always a little nervous when I spend 45 minutes talking to an empty room, because it's hard to tell whether I'm going too fast or too slow, too complicated or too simple. Your feedback really helps when targeting future episodes.

LeeCampbell> As a C# dev this helped me understand the syntax (:: << etc) more than anything.

I'm glad to hear that. My goal in all of these episodes is to give you a taste and a general overview of the topic, making it easier to understand other videos/articles/books.

LeeCampbell> Most of the rules seem quite similar to the C# rules which is nice.

"Wow, people in Britain speak a language that's really similar to America's!" :->

kayvan> 0) C/C++ run-time startup functions,lifecycle, ie: initialization, how C/C++ startup function calls your application's entry-point function

This is outside my area of expertise (as far as I'm concerned, magic invokes main()), but I bet Charles could ask our CRT maintainer, Mahmoud Saleh, to cover this.

kayvan> 1) Virtual functions and the Run time cost of virtual functions & dynamic binding. kayvan> 2) forward declaration.  Forward declaration of template classes

Got it. I was definitely planning to cover virtual functions (in particular, my favorite NVI idiom), but I had forgotten how important the subject of declarations versus definitions is. I'll cover that at the first available opportunity.

kayvan> 3) difference between template <class T> MyClass [and] template <typename T> MyClass

There is none! :-> (Only template template parameters care about typename versus class - and that is not a repeated word typo.)

I personally prefer "typename", because "class" has confusing connotations (it does NOT restrict T to class types; int remains perfectly acceptable).

AceHack> I'm also curious about typedef

Cool. I'll see if I can cover this in an episode along with other smaller features. (Unfortunately I can't demonstrate C++11's alias-declarations with the "using" keyword.) There are nontrivial bits here, like typedeffing function pointers.

AceHack> and as much as possible about the Preprocessor if that's considered part of the core c++.

It is, although the preprocessor is really a primitive text-manipulating language that's applied before C++ itself is compiled.

Chris> What I love about C++ is its complexity and that some operations in the language are undefined.

Of course, C++ doesn't go out of its way to be complicated. Most of the complexity is there for a reason - usually to support tricky code, sometimes to support backwards compatibility (as obnoxious as it may be, C++'s compatibility with C remains a strength).

As for undefined behavior, that usually exists because something is difficult to detect, and leaving it undefined permits significant optimizations.

Ivan> I barely managed to watch this episode, but not because STL is bad but because I really dont care that much about language rules

Heh. Remember, I'm not really interested in the Core Language as an end in itself. It's just that because it underlies all programming, and as a library developer I deal with very tricky code for a living, having a thorough understanding of Core is invaluable. It lets me write code with a complete understanding of how it's going to behave (users can do lots of things with the Standard Library and we have to be prepared for the crazy stuff they're going to inflict on us). Understanding the Core Language also makes it a lot easier to understand compiler warnings and errors. That speeds up my development cycle, and having no fear allows me to use complicated constructs more extensively. (Some programmers, fearing template errors, avoid templates when they would be a superior solution that would allow them to write cleaner code.)

Ivan> 1. Regarding episode 2 dont forgett to mention pointer paradox.

I haven't heard of that - perhaps I know it by another name.

Ivan> 2. Do you know why there arent trie_(multi)set and trie_(multi)map in boost or std? To obscure?

The Boost Graph Library could probably be used to construct tries. Both Boost and the Standard are developed by volunteers, so they consist of things that someone has had the time and motivation to develop/specify.

(I got started with C++ by implementing suffix trees, which are a special case of tries.)

Ivan> 3. One of the cool lectures (using TMP) would be solving this problem (if possible) : http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Graham-Hutton-Functional-Programming-Fundamentals-Chapter-11-of-13 with TMP

Interesting - I will see if I can find some time to play around with it (which is how I did my Nurikabe episodes). http://www.cs.nott.ac.uk/~gmh/countdown.pdf formally specifies the problem.

Ivan> 5. Idioms are a cool topic imho. Like I said I dont care that much about lang rules, but I like learning idiomatic way of programming in language X.

I'll definitely cover the Non-Virtual Interface idiom.

dot_tom> I've been using this language for almost 18 years and Stephan clear up some of the name resolution stuff for me in this video.

Sweet!

Guest> I actually have one question when you std::cout something in c++ why don't you include just iostream and you include ostream too I think iosteam will provide the ostream functions and objects too.

This is actually an interesting story. In C++98/03, <iostream> provides cout but not endl, which lives in <ostream>. I followed those rules strictly. In C++11, <iostream> is now required to include (or behave as if it includes) <ostream>. I actually just learned this at BoostCon/C++Now! 2012, and one of my todos when I get back to Redmond is to check whether we've implemented this in VC11.

> Another, perhaps more far-reaching question -- if/when this gets supported, will there be an integration with STL, such as, say, std::inner_product would automatically make use of the above instructions where applicable?

One of my todos is to go through the STL and look for opportunities to make our algorithms more friendly to the autovectorizer.  I believe that this will be mechanically very simple, if all that's necessary is detecting raw pointers at compile-time (either all raw pointers, or just raw pointers to scalars) and using index-based instead of pointer-based loops.  Such compile-time logic is trivial in the Standard Library (we have tons and tons of it already, some to call memmove()/etc.), it's just that the STL has a lot of algorithms and auditing them to figure out which ones would benefit will take time.  I won't be able to get to this for VC11 because it's "nice to have" and I've been dealing with must-fix issues, but it is definitely on my radar.

> Is there a similar feature in plans [to libstdc++'s profile mode]?

I've heard of that, but I haven't heard of user experiences with it, nor am I convinced that it is actually useful in practice.

(never mind)

c9xeo> Great talk, it's always a joy to hear you talking!

Thanks!

c9xeo> I hope you'll have a little bit more time for your Advanced STL series once VS11 is out.

Me too. You can think of this as "Advanced STL, Part Infinity" for the time being. :->

c9xeo> Then, any particular reason that nearly every slide was titled with a TVTrope?

I came up with "Twenty Minutes Into The Future" and "The Reveal" first, and I liked them so much, I had to follow the pattern. :->

c9xeo> (Also, can we get access to these slides?)

The links are above: "Slides (view online)"

someone> What are cars, putters and stoods??!

I pronounce "char", "ptr", and "std" as "care" (it's the prefix of "character"), "putter", and "stood".

C64> So, when we have a C++ class X and we want to modify a copy of it inside a function/method, does it make sense (also in C++98/03) to always use signature like your #2?

Yes. It's sometimes better, and never worse. The advantage increases in C++11, but is present in C++98/03.

I was taking shortcuts - move semantics would have been involved if the sources were str + "stuff" - but the point still holds.

Compare:

flip(const string& s) { string ret(s); // #1, reverse and return ret

versus:

flip(string s) { // #2, reverse and return s

Given flip("meow"), #1 creates a temporary string, binds the const reference s to it, then (unnecessarily!) copies it into ret. #2 constructs s from "meow", as you mentioned, then flips and move-returns it.

So, #2 made sense even in C++98/03, and it plays nice with move semantics.

NotFredSafe> I'm a bit surprised STL did not comment on this since. Unless I'm mistaken, this issue is one of his pet peeves

I missed it.

thesaint> Nobody is talking about push_back...

What are you referring to, then?

vector always grows geometrically, not arithmetically. This is true for push_back(), emplace_back(), element insert(), range insert(), resize(), everything. The lone exception is reserve(), which is permitted to give you exactly as much memory as you ask for (and typically will), which can trigger quadratic complexity if you're not careful (I've hit this myself).

thesaint> The key difference between "list" and "vector" is that, unless I am forgetting some "list" members here, "list" is just plain useless.

Not quite - it has very nice invalidation guarantees.

The range-based for-loop is significantly less verbose than std::for_each() (my least favorite STL algorithm).

But using more specific STL algorithms is always a good idea.

> I am confuse on how you can talk about the difference between list and vector in performances because of their layout and design and at the same time say that you shouldn't teach student about cache lines, and the low hardware stuff.

1. vector and list are massively different in terms of what you can do with them - vector has op[], list has push_front, etc.  In contrast, caching effects don't affect what you can write - only how fast it is.  (Hardware engineers go to great lengths to preserve the illusion that memory is flat and simple!)

2. vector and list affect asymptotic complexity (this was the point of Bjarne's once-invisible graph) - yay computer science!  Caching effects do not.

3. The difference between vector and list is very simple to explain - it can be explained to beginning programmers with simple diagrams.  Caching effects are not as simple.

4. The difference between vector and list is fundamental and architecture-independent. Caching effects are strongly architecture-dependent (and have changed over time).

5. It is easy to deal with the difference between vector and list - use vector as your default sequence container because it's so awesome. It is not trivial to write code that respects cache lines and so forth.

When I'm explaining vector to beginners, I usually say, "Look, it's contiguous. This is space-efficient, and processors love blasting through memory in a straight line", and leave it at that.  That's all you need to know when you're starting out.