CppCon 2019: Conor Hoekstra “Algorithm Intuition (part 1 of 2)”

—
—
—
Data structure intuition is something that develops naturally for most software developers. In all languages, we rely heavily on standard containers and collections. Need fast insertion/lookup? Hashmap. Need a sorted data structure that stores unique values? Set. Duplicate values? Multiset. And so on.

However, most software developers don't develop algorithm intuition quite as easily. Algorithms aren't taught as widely as data structures are, and aren't relied on as heavily. This talk aims to introduce some STL algorithms, show how they are commonly used, and show how by developing intuition about them (+ a little help from lambdas), you can unlock their true potential.
—

Conor Hoekstra
Amazon
Software Development Engineer
San Francisco Bay Area

Conor is extremely passionate about programming languages, algorithms and beautiful code. He spent 5 years in Canada working on a large-scale C++ codebase. In 2018, he moved down to Silicon Valley and has spent the last year working for Amazon using C++, Java, Python, Go, Perl and more. He is in the midst of falling in love with Haskell and functional programming. He also has a YouTube channel where he covers solutions to competitive programming problems and more.
—

*-----*
*-----*

[MaxCoplan]

57:04 "The efficiency is unparalleled". Actually, the efficiency is very parallel

[ThomasThomassen]

The ! post-fix in Ruby is used when you have both a mutating and a non-mutating version. For when you have .strip and strip!. Concat doesn't have a non-mutating alternative, so it doesn't feature ! postfix. This is how the Ruby Core has been using it. But many have misinterpreted that as a mutator signal or "dangerous" signal. But those patterns are not consistent in Ruby code bases.

[NoNameAtAll]

19:22 I would've added const to the _vector_, not iterators... and iterators would've followed constrants of their origin...

[dunga]

I don't see any coolness in the trailing return type. I you could omit auto keyword at the start could be

[eugnsp]

1) Using a signed `int i` for an index and then comparing it to an unsigned `size()` is definitely not a good idea; 2) `v.size()` could be replaced with `size(v)` for consistency, or, in C++20, with `ssize(v)` to address the previous point; 3) `--end(v)` might not even compile, e.g. if `end(v)` returns a raw pointer, which is a valid iterator type for a vector.

[alcesmir]

About the memory in the adjacent difference example. You can just do it in place (output to the original vector). Also I get the frustration that adjacent difference has the first element left in it's place, but there is a good reason for it. Adjacent_difference and partial_sum will undo each other with the chosen standard.

[abc]

Many of the examples presented are buggy as overflow or underflow possibility, UB for int, is ignored.