Beginners Guide to C++'s Best Kept Secret -- std::algorithm - Mike Shah - C++ on Sea 2022

[@MikeShah]

Thank you again C++ on Sea for having me! It was a truly wonderful event!

[@pUrbanNinja]

Super smooth talk! I was really surprised that you went down the optimization path at all! For some reason, quite some students and non-cs researchers still assume that the STL implementations perform worse than raw loops. My favourite debunking-example is a dot product of 2 large vectors using inner_product, which gets vectorized without issues.

[@rohrbold]

Super important topic. Thanks for the presentation Mike.

[@cpponsea]

Thanks for watching!

[@MikeShah]

Thank you!

[@loicballeydier5546]

I would love some slides about how c++20 ranges can simplify and boost performances of the code you finally get. But great talk !

[@MikeShah]

Great idea! Maybe next year's talk I can do a deep dive or some more shorter videos on my channel in the meantime.

[@ABaumstumpf]

it is strange seeing somebody saying that "i++" might cause additional copies and being slower - and then changes "[i]" to "at(i)" - which is slower and at that a significantly bigger impact than "i++" can ever be. And i would say that using "at" is a codesmell here: When iterating over a container of known size, and at that iterating over all elements, there is no uscase in which "at" does actually do anything useful. And iterators: They certainly are not easy to maintain. They are already a royal pain just to write out correctly and the introduce pointers on everything. For us if you write an iterator-loop like that it would be rejected in the code-review cause they serve no purpose here, do not make it easier to read, write not maintain and obfuscate the important parts. (And they are also more error-prone if you are doing any element-manipulation). Ranges has (nearly) done what iterators should have from the start (just that the syntax and behaviour has many pitfalls and in C++20 several of the most important functionalities had been "forgotten" ).