> Sometimes i do trust the compiler a bit too much thinking its smart enough to understand what i'm doing when it can be really stupid and stubborn sometimes.
Compilers are good at micro-optimization, bad at macro-optimization. Humans are the reverse.
> When ever i see 'back_inserter' i think of performance loss. Is that incorrect ?
It's very convenient, and avoids length-related errors. However, for performance-critical code, capacity testing on every push_back(), and occasional reallocation, are significant.
> What do you think about that 'find_if' "optimization" ?
It's reasonable, but the test afterwards is still unnecessary.
> 6. Nice catch. Btw how big of an issue is that ? Cant the compiler optimize that away ?
Maybe, maybe not.
> That surprised me a bit. Isn't (&&) and std::move's main reason for existing just because of reducing reallocation overhead ?
They exist to eliminate unnecessary dynamic memory allocations and deallocations, which can be triggered by temporaries or vector reallocation, etc.
> Now i'm a bit confused. When writing algorithms shouldn't you have reallocation overhead in mind or are there some simple guidelines you can follow ?
Yes, but you should also count your operations. 2N is a lot bigger than N.
> 10. But it will not hurt performance right or is it bad in some way ?
Shouldn't affect perf, it's just unnecessary.
> Explain more, please.
I was assuming that the whole source range would be discarded.
> How big of an issue is it really that move_if use forward iterators ?
Someone with input iterators who wants to use your algorithm will be sad. That someone may be you.
> I'm beginning to understand the many decisions you must be making working on the STL for every single function.
:->
> How do you know when to stop: optimizing / correction cleaning and move on to the next thing ?
I just try to fix bugs until my bug count reaches zero. I also fix todos on my todo list when I'm in the neighborhood.
