Yeah you probably DO understand std::vector which is what I said.

You probably don't understand std::list and std::deque forget std::rope std::map std::unorderd_map, std::set etc. etc.

I know I don't. I know what they do, I know how they're probably implemented. I know their big O characteristics etc. But they're optimised for high level generality not for the thing I'm doing on the hardware I'm targeting. I don't know how they perform on particular hardware, how cache sizes affect them etc etc etc. You have to find that out for yourself, hopefully by benchmarking before you use them, rather than finding out they suck very, very hard in production.

Bjarne Stroustrup himself as chief c++ booster says: "Everybody gets this wrong" when comparing something as simple as std::vector to std::list in performance.

"Everybody gets this wrong" --Bjarne Stroustrup

Maybe you're smarter than the rest of us, it's entirely possible but the rest of us use this language and that's what I'm talking about here. Eh see for yourself.

https://www.youtube.com/watch?v=YQs6IC-vgmo

Note that the benchmark he shows is not available, and it's not available in the STL. It might perform completely different on your embedded project. Eh so you have to write this benchmark (and all the others you might need) yourself. Write it every time you need to use an STL container that isn't vector and you care before you have the evidence you need to reject it. Seriously. WTF is up with that?

You have to care? Write your datatructure and algo yourself, you can reason about how the memory is used, how the caching performs. How the compiler vectorises, inlines it. You have an idea of the assembly language that will be generated (or at least you should). If you look at an STL implementation you feel your eyes bleed. It's ridiculous, what instructions will the compiler produce, hell what c++ code will it even compile?

But if you dont' care it's fine - and there are great reasons not to care. Being in a situation where you don't have to care is awesome, use them. Eg setup code that can be slow before you get the the stuff that has to be fast.

I have never seen an exception safe C++ codebase, I don't believe such a beast exists. Even if it does it's a properly hard problem that you can't keep in check with multiple committers. Just see how much time Herb Sutter and Alexandrescou (who has now dumped c++ as needing to become a legacy language) put into trying to explain how to do it. And failing to do so. The idea "exception safe" in c++ easy is only entertained by those who don't understand the problem. Scope guard is not a magic bullet. How does the silly contrived example of opening a file work with multiple threads? Look at his example, push_back of a pointer onto a vector. I've never seen anything other than

vec.push_back(ptr); //get on with life

in the wild. But hey, maybe I'm missed some and it's only 99% of c++ code that is by the Alexandrecou definition "exception unsafe" Maybe 99% of c++ programmers aren't smart enough to program in the language?

If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. Haskell might, python, ruby, scheme might.

The whole point of C and C++ is being able to get that really low level performance.

Yes totally, I DO recommend "monkeying with text generation" because you won't do it unless you actually need to. Templates have the opposite characteristic, sadly.

(And just quietly, to hell with the bozo who voted me down to 0 for participating in this discussion, you're not very bright, responding as maxlybbert did is the correct thing to do if you disagree, disagreement is what this whole thing is all about otherwise why bother?)