Orthodox C++
gist.github.com
gist.github.com
Speaking of printf, I meant its counterpart, like boost::format; it accepts format strings but is safe. It can throw an exception in case of an error, and a programmer can react accordingly.
I hate C++ streams, they're slow and cumbersome, one of the worst solution ever. I think lack of format string is their main problem.
Most of this is really about specifics of your situation. Yes, pay attention to what's supported by compilers on the platforms you need to support. Yes, pay attention to memory usage and performance characteristics of the STL (but that's just part of being a good engineer, and the performance behaviour of STL constructs is part of the spec so it's not exactly hard to find out). Yes, use your own data structures where they fit your use case better than the STL ones.
But that doesn't mean, in general, that you shouldn't be using vectors. You just need to be aware what it's doing, and use intelligence and data to profile things properly when you're assessing whether the performance and memory usage of your code is acceptable.
Really, this feels more like specific guidance for a specific project that has specific requirements from its target platforms.
Except the bit about staying comprehensible to C programmers. C wasn't some mystical nadir in language design, and C programmers have brains. If they want to use C++ they can sit down and actually learn it, radical though that idea might be.
I was always radical since the 90's, the C vs C++ discussions we have nowadays, I used to have them on USENET.
Even before C++98, the language already provided a sanity path to get rid of many of the typical C exploits and programmer errors, but those guys will never leave C.
Which with the success of free UNIX clones like *BSD and GNU/Linux, means we will never get rid of it until there is a radical change in computer architectures.
I don't even know what to make of this. If you can't afford to use dynamically allocated memory at all, then there's nothing special about STL, you need to avoid all libraries that call malloc(). If you ask somebody why they are using `float* ptr = (float)malloc(sizeof(float) array_size)` instead of `vector<float> vec; vec.reserve(array_size)`, and their answer is "because STL is slow", run away. If someone complains about std::allocator being stupid, they have a point, but you still have a program that isn't going to write itself, and just because std::allocator is stupid does not mean that STL is categorically awful.
What is true is that you should understand the overhead of things like std::set<> and std::map<>, and how to get avoid that overhead when you need to, but this recommendation is basically a tiny subset of the recommendation "understand and use Modern C++".
I think the idea (as seen in traditional high-performance C++ code) is to be very aware of allocations. Dynamic memory allocation is slow; sometimes, the slowest part of one's code. So it's fine to use a library that calls malloc() behind your back for small, occasional allocations (whether that library is the STL or libc or any of your other dependencies), but not in your inner loops, and not for your multi-GB data structures. Instead, manage your own buffers, size them right from the beginning using application-specific logic, realloc exponentially if you need to (but hopefully you don't need to), and use placement new to construct your objects in your buffer in a way to optimize access locality.
To me the trick is not to have magic things in the code, but instead use the language to the best of ones ability to write simple non-magical code. Unlike in the article I include things like smart pointers and the STL as some things helping me do this.