6 ms·

Modern C for C++ Peeps

• harry8 7y ago
  This is a nicely written piece. Worth your time if you program much c, c++, rust, D, go etc.
• objektif 7y ago
  I like the color theme of this page very much. Anyone knows what it is?
  • marvo 7y ago
    Looks kind of dracula-esque with monokai syntax highlighting
• jackewiehose 7y ago
  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
  • ncmncm 7y ago
    The useful subset, not coincidentally.
    • jackewiehose 7y ago
      Which subset you wouldn't consider useful?
      • ncmncm 7y ago
        Out-of-order initialization, and multiple initialization, have limited usefulness.
• dottrap 7y ago
  Very nice article! 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).
• legends2k 7y ago
  I tend to disagree that RAII is used only used for memory. We've RAII wrappers for locks, file handles etc. all the time in our code base. 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 :)
• tom_mellior 7y ago
  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.
  • dottrap 7y ago
    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.
  • vips7L 7y ago
    The kernel style guide also says you shouldn't typedef structs.
• sagarm 7y ago
  tl;dr: 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.
  • ncmncm 7y ago
    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.
  • jplayer01 7y ago
    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?
• ncmncm 7y ago
  From the article: "The ‘Modern C’ I’m talking about here is not modern at all, but already two decades old." No kidding! Still, anybody coding C is still, within epsilon, coding C++, but badly.