It is written from the perspective of amateur. C++ exceptions comes at no cost. RTTI comes at no cost. C printf is unsafe; one can write perfectly safe printf-like formatters in C++ (did it, works well). Why one can use metaprogramming but not STL? A programmer can plug a custom allocator in STL containers, if an allocator is a problem.
C++ exceptions definitely come at some non-zero cost, albeit very small on the happy path, both in terms of runtime and code size. RTTI also comes at a cost of higher memory footprint, but more importantly relying on RTTI is a sign of bad design in most cases. C printf is unsafe, but most IDEs figure this out and show appropriate warnings. The biggest problem with C++ streams is not lack of printf-like formatters, but the fact that formatting is part of stream state and is not as clearly separated from the printed content as in printf.
It was comparison posted at HN -- exceptions were more efficient in case of deep stack unwinding, when compared to testing return codes. But of course, they are not totally free. RTTI memory footprint is negligible in practice; I work on a huge application, having thousands of classes. Nobody cares about the size of RTTI structures, it was never a problem. (Lack of standard API for RTTI is a pain in the neck -- GCC has nice non-standard solution, but MSVC has nothing.) I agree with you that overusing RTTI, like dynamic_cast, might be a sign of design flaw.
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.
But why? It doesn't really explain the purpose of this. What is it about Modern C++ that the author doesn't like? It could easily be read as a person who decided that C++ has too many things which are new and different and they couldn't be bothered to learn them properly so now has to tell everyone not to use them.
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.
> 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.
The prohibition on anything in STL that allocs mem is odd. I've been coding in C++ since 92, and started using STL and templates in earnest circa 2002. In the early 90s we were still in the C front world and template support wasn't mature. By 2002 templates were well supported, and STL's mature container code was a big step forward in terms of abstracted but deterministic memory management.
> Don't use anything from STL that allocates memory, unless you don't care about memory management.
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++".
> 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().
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.
This is another one of those articles saying that people tend to overuse easy-of-programming and language power features to the detriment of speed/efficiency (of compiling and perceived execution) and understanding. While this sort of argument has some merit, in that typically new features are overused just after introduction, it basically relies on the infallibility of the programmer not to make simple mistakes.
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.
It is written from the perspective of amateur. C++ exceptions comes at no cost. RTTI comes at no cost. C printf is unsafe; one can write perfectly safe printf-like formatters in C++ (did it, works well). Why one can use metaprogramming but not STL? A programmer can plug a custom allocator in STL containers, if an allocator is a problem.
C++ exceptions definitely come at some non-zero cost, albeit very small on the happy path, both in terms of runtime and code size. RTTI also comes at a cost of higher memory footprint, but more importantly relying on RTTI is a sign of bad design in most cases. C printf is unsafe, but most IDEs figure this out and show appropriate warnings. The biggest problem with C++ streams is not lack of printf-like formatters, but the fact that formatting is part of stream state and is not as clearly separated from the printed content as in printf.
On C++ streams: see http://fmtlib.net/
It was comparison posted at HN -- exceptions were more efficient in case of deep stack unwinding, when compared to testing return codes. But of course, they are not totally free. RTTI memory footprint is negligible in practice; I work on a huge application, having thousands of classes. Nobody cares about the size of RTTI structures, it was never a problem. (Lack of standard API for RTTI is a pain in the neck -- GCC has nice non-standard solution, but MSVC has nothing.) I agree with you that overusing RTTI, like dynamic_cast, might be a sign of design flaw.
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.
But why? It doesn't really explain the purpose of this. What is it about Modern C++ that the author doesn't like? It could easily be read as a person who decided that C++ has too many things which are new and different and they couldn't be bothered to learn them properly so now has to tell everyone not to use them.
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.
> 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.
More like Amish C++
This!
The prohibition on anything in STL that allocs mem is odd. I've been coding in C++ since 92, and started using STL and templates in earnest circa 2002. In the early 90s we were still in the C front world and template support wasn't mature. By 2002 templates were well supported, and STL's mature container code was a big step forward in terms of abstracted but deterministic memory management.
> Don't use anything from STL that allocates memory, unless you don't care about memory management.
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++".
> 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().
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.
This is another one of those articles saying that people tend to overuse easy-of-programming and language power features to the detriment of speed/efficiency (of compiling and perceived execution) and understanding. While this sort of argument has some merit, in that typically new features are overused just after introduction, it basically relies on the infallibility of the programmer not to make simple mistakes.
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.
Just when I thought C++ started to become a sane language again.
Having second thoughts about the bgfx library now.