> 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.