This is such a great talk and overall good advice and contribution, so I hate to nitpick, but unless you're an ardent user of rotate() I recommend looking up its arguments before watching this, as the slide animations show movement rather than rotation, and confusingly use rotate(first,last,position) while most documentation says rotate(first,new_first,last) or rotate(first, middle, last)! To a visual learner, rotate effectively circularly shifts all entries within a band (args 1 and 3) until the entry that used to be at index 'first' is now at index 'middle'. All entries that "wrap around the edge" when doing this rotation will appear to have "moved". It's this last effect that is useful and appears to be the mental block he's encountering in others. For sure, people should look things up themselves, but if people don't understand something, maybe you didn't explain it well? That said, the overall advise is spot on and a great contribution!
In the slide function, I really wish he would define what is 'p' exactly. In one case (p < f), p is the desired beginning of the selection and in another case (p > l) it is the desired end of the selection! This increases the burden on the caller of the slide function as the semantic of parameter 'p' depends on its value relative to the other parameters which isn't great design. The gather one is beautiful though. Memorising it.
It is all good, but there is a problem nobody talks about - you end up with hundreds, potentially thousands of algorithms (functions) that you need to keep in your head. Quote often it is much easier for me to write a loop, than to remember whether I have an already implemented algorithm somewhere. Standard library is huge, and quote often names of algorithms are not good. Is rotate() adequate name for what it does? - My humble opinion is NO. Examples are numerous, not just in C++, but in D and other languages as well.
+Dejan Lekic In all fairness though, with the existence of search engines / Stack Overflow, does it become necessary to memorize every algorithm or function call? Not to mention there are web-based resources that should provide all the information you need without excessive memorization. And anything you're using frequently enough, you will memorize by practice.
Besides the other replies it how long would it take to you to write the foolproof code and what about the efficiency of your code. Instead when you use algorithms you are inheriting the other clever peoples work.
Remarks like "Because no one knows what rotation is." from senior programmers are indeed amazing.
This is such a great talk and overall good advice and contribution, so I hate to nitpick, but unless you're an ardent user of rotate() I recommend looking up its arguments before watching this, as the slide animations show movement rather than rotation, and confusingly use rotate(first,last,position) while most documentation says rotate(first,new_first,last) or rotate(first, middle, last)! To a visual learner, rotate effectively circularly shifts all entries within a band (args 1 and 3) until the entry that used to be at index 'first' is now at index 'middle'. All entries that "wrap around the edge" when doing this rotation will appear to have "moved". It's this last effect that is useful and appears to be the mental block he's encountering in others.
For sure, people should look things up themselves, but if people don't understand something, maybe you didn't explain it well?
That said, the overall advise is spot on and a great contribution!
Shut up, publish your book and take my money!!! haha As always a great talk of Sean Parent!
In the slide function, I really wish he would define what is 'p' exactly. In one case (p < f), p is the desired beginning of the selection and in another case (p > l) it is the desired end of the selection! This increases the burden on the caller of the slide function as the semantic of parameter 'p' depends on its value relative to the other parameters which isn't great design. The gather one is beautiful though. Memorising it.
I WANT that book AS SOON AS IT will be published! It will be sitting (and used) next to "Code Complete"
thanks. another excellent presentation. just the first part ah ! it really reminds me of that old good book Software Tools [in Pascal] : )
Well, the Google engineer instead knew how to jump out of a blender :-)
Boost lambda's can deduce their argument types...
genious
It is all good, but there is a problem nobody talks about - you end up with hundreds, potentially thousands of algorithms (functions) that you need to keep in your head. Quote often it is much easier for me to write a loop, than to remember whether I have an already implemented algorithm somewhere. Standard library is huge, and quote often names of algorithms are not good. Is rotate() adequate name for what it does? - My humble opinion is NO. Examples are numerous, not just in C++, but in D and other languages as well.
+Dejan Lekic In all fairness though, with the existence of search engines / Stack Overflow, does it become necessary to memorize every algorithm or function call? Not to mention there are web-based resources that should provide all the information you need without excessive memorization. And anything you're using frequently enough, you will memorize by practice.
You prefer having to read a loop every single time just to figure out what it does every single time? You prefer not having composable algorithms?
Besides the other replies it how long would it take to you to write the foolproof code and what about the efficiency of your code. Instead when you use algorithms you are inheriting the other clever peoples work.
it is big part of profession to keep them all in mind