Wonderful talk. I will recommend this to my students who are struggling to learn C++ in the midst of these fluidic standards paradigm shifts. Not for any particular detail, but as a wonderful overview of the situation from a learned perspective.

Great talk! Very clear, unpretentious and informative. and are our new best friends. Raw loops are 90's technology 🙂

Thanks for the great talk Roger Orr. The talk was well presented and helped to solidify existing understandings and even shone the light on somethings which I didn't know.

24:00 - it shouldn't work with a collection of complex numbers, because result has type int, and std::complex doesn't implicitly convert to int. I tried compiling this in godbolt, and the compiler rejected the *= operation, as expected: int product(const std::vector& xs) { int result=1; for(auto& x: xs) {result *= x;} return result; }

A brilliant talk, very well delivered, thanks Roger!

27:31 Sean Parent’s “No raw loops” talk: kzfaq.info/get/bejne/p65mpraA15Pdm2w.html

What I'd like to see with regard to iterators is something like what I've added to my language where you can designate the return value as completely discardable so the compiler can optimize iterators and not have it++ perform any differently to ++it, regardless of trivial construction. As far as string logging, I personally detest the separated construction of a string to then be converted to another format and then finally be logged. This is why logging functions should be in a similar format to the *printf() family of functions, so you can make a single function call to log a whole mess of data in one call. I've never liked the format for constructor initializer lists either, especially that it requires duplicating names and using parentheses when a simple equal sign would be better, and then you still have to use braces to signal that its a function definition and that it should do something even if everything it does is initialization that's already been defined. It's not like the compiler can't optimize initialization without using this special syntax, or even that I would advocate specifically for doing it in the function body, but when there's nothing to be done but copying values taken by the constructor it'd be nice if instead the compiler could fill in the boilerplate for you. Although, I very much doubt the standard committee would want to adopt my methodology, so this will likely never get resolved to my satisfaction in C++.

11:51 This is one of the most confusing things about C++ (and there are many) since I started learning it (kinda-sorta at the announcement of C++11, but mostly the last five years). I read some years ago that ++idx was preferred (it runs faster/is more efficient) over idx++ for some arcane reason that I couldn't follow at the time, but it made no sense. I've been using i++ in for loops in C since 1986, but NOW I gotta change. I've since seen Godbout's compiler talk that showed me some amazing optimizations that compilers do, why can't a compiler see that the "returned value" of this expression isn't used, so it makes no difference how it's incremented or whether it needs a temporary to hold the preincrement value. As the speaker says, yes it does figure that out with an int, but an object makes it complicated ... this is a gotcha with C++, it's supposed to be a "higher level language" but it's remarkable how much lower-level detail one has to know about the compiler in order to write the most efficient or "best" code.

I would be interested in the stories between the two hands up who found bugs in std::accumulate.

55:56 the call to log function changed from log(oss.str()); //oss is std::ostrstream to log(std::move(oss).str().c_str()); //oss is std::ostringstream they should've just provided a c_str() method for std::ostringstream so it would just have been log(oss.c_str()); //oss is std::ostringstream but changed I wonder why they went with approach in P04087 instead of just doing this

How I do reverse loops: int i = my_max_value; while (i--->0) { // do stuff }

That loop from 15:32 could be written with idx--> 0. It means the same (loop when idx-- is not zero), but it looks like a nice cute arrow and for that reason is often mentioned as a "secret arrow operator" in C, and that jocular exposure makes it idiomatic for a small, but not insignificant number of programmers.

In my opinion demonstration of how simple loop can be implemented in 100 different ways demonstrates the fatal genetic illness of C++. And lack of will of C++ community to disavow backwards compatibility and solve them once and for all.

I hate putting the ampersand and asterisk signs left-aligned. I teach newbies by asking this: int* a, b; and then I ask the type of variables. Most of them say they are both pointers. No, they are not.

The problem will most modern programming languages that have a large "market share" is that they're not driven by engineering or science anymore, but by mere competition. C++ gas grown into this monster only in an attempt to keep its market share, or even grow it. (Call that user base if you prefer.) Any newer language that would introduce some new paradigms or even just some new sugar coating would become an inspiration for the next iteration of C++. Just to prevent developers from moving away. That's just plain marketing. And marketing does infect everything it touches.

In the strangest way, C++ forces you to learn more about low level stuff more than you need compared to C. You suppose to use the "high-level" zero-cost abstraction and features, but it always has a "gotcha". It is more troublesome than useful. I can see it slowly "evolving" into a legacy language, what an oxymoron.

"modern C++" shouldn't be called C++ anymore, the people who wanted so many changes in the language, effectively subverting this pretty good language, could've, at least, had the decency to change the name, let's say D++ or C+++ or something else, like when they added OOP to C and changed the name

Yep. That's exactly why the modern one sucks.