I cannot really read the article. It's too depressing because I'm still stuck with C++03.
But even before the newer C++ became widespread, I wondered why it lacks behind C99 in some aspects. And it seems that this hasn't changed much:
> The good news is that C++20 is getting basic designated initialization too, the bad news is that it will only be a very limited subset of the C99 feature
I disagree with the "always typedef structs" part. Personally I often find it nicer to have the "struct" there as part of the name. Partly because people sometimes typedef a pointer to the underlying struct type, and that can cause some issues.
The part about the author's take on RAII is interesting, but it would really merit a separate post with code examples.
I first read about the style of not typedef'ing structs in the Linux Kernel style guidelines. I read some of the justifications and the pointer issue you also bring up is a really convincing one. But I was also convinced by the context argument. I've seen Linus use this one to talk about the downsides of using C++, but it also applies here. Basically, when reviewing a small block of code, it is typically possible to understand what the code does in C (whereas in C++, because of all the language features that kick in automatic implicit behaviors, it is much harder to know if any of that is going on without much more context.) Similarly with the explicitness of struct, you know exactly what is going on and you don't have the ambiguity of whether the type is a struct, pointer, or primitive type (like int) and how they impact the behavior slightly differently in the language.
I suggest -pedantic as well; surely you were already using the first two?
2) designed initializers are nice
Indeed, they are.
3) you don't need RAII because it's only for memory
False. C++ is my main language, and we use RAII in many ways: callback invocation, taking locks, pinning cache items, timing segments of code, etc etc.
4) small allocations are bad
Small allocations are indeed highly inefficient, but this can be addressed using arena allocation. This works because it's actually the deallocations and associated defragmentation that are expensive.
5) ...so the solution for memory management is not to have structs that contain pointers (?)...
You should use the simplest data model possible, but only the simplest data models don't require having pointers in structs. For example, any recursive structure would have to have a pointer.
6) and all your objects should be allocated from object specific free lists
Having an object pool doesn't address memory leaks. You would still have to return the object to the pool at some point.
A good summary. Notably, none of these constitutes any sort of argument against just compiling with the C++ compiler, and relaxing into its objectively superior for-loops and std::array types -- to start with.
Once there, of course, the objectively more powerful, safer, faster (than can be coded in C) C++ libraries come into reach, and you are off to the races. If you have been deluded that C++ is all about virtual functions and heap allocations, you are in for a happy surprise. (My programs run for days or weeks using neither.) The most distinctive development in C++ in the past decade is that it is overwhelmingly more fun to code in, than before, and than C.
Different people trace the fun to different places, but for me it centers in generic lambdas. I like to use them to invert control structures and cut down repetitive code.
Is arena allocation something that you implement anew for every project or is there a suggested library or...? New to C++. Also, how does this interact with smart pointers?
16 comments
[ 3.4 ms ] story [ 53.1 ms ] threadBut even before the newer C++ became widespread, I wondered why it lacks behind C99 in some aspects. And it seems that this hasn't changed much:
> The good news is that C++20 is getting basic designated initialization too, the bad news is that it will only be a very limited subset of the C99 feature
Minor nit: > there’s now a standardized bool with true/false (also not built-in but defined in stdbool.h)
C99 introduced _Bool, which is a built-in.
stdbool.h defines bool as an alias to it (unless compiling as C++, which then gets left alone as the native C++ bool).
Also it's impractical to only have POD structs i.e. structs with no pointer pointing to the free store.
Good otherwise.
Nice colours and theming though :)
The part about the author's take on RAII is interesting, but it would really merit a separate post with code examples.
1) use -Wall, -Werror, -W4.
I suggest -pedantic as well; surely you were already using the first two?
2) designed initializers are nice
Indeed, they are.
3) you don't need RAII because it's only for memory
False. C++ is my main language, and we use RAII in many ways: callback invocation, taking locks, pinning cache items, timing segments of code, etc etc.
4) small allocations are bad
Small allocations are indeed highly inefficient, but this can be addressed using arena allocation. This works because it's actually the deallocations and associated defragmentation that are expensive.
5) ...so the solution for memory management is not to have structs that contain pointers (?)...
You should use the simplest data model possible, but only the simplest data models don't require having pointers in structs. For example, any recursive structure would have to have a pointer.
6) and all your objects should be allocated from object specific free lists
Having an object pool doesn't address memory leaks. You would still have to return the object to the pool at some point.
Once there, of course, the objectively more powerful, safer, faster (than can be coded in C) C++ libraries come into reach, and you are off to the races. If you have been deluded that C++ is all about virtual functions and heap allocations, you are in for a happy surprise. (My programs run for days or weeks using neither.) The most distinctive development in C++ in the past decade is that it is overwhelmingly more fun to code in, than before, and than C.
Different people trace the fun to different places, but for me it centers in generic lambdas. I like to use them to invert control structures and cut down repetitive code.
No kidding!
Still, anybody coding C is still, within epsilon, coding C++, but badly.