4 ms·

Anyone know of a better blog/reference for why to use C over C++ today? I'm still writing some of my own stuff in C but honestly I think that's inertia. Freesta

Anyone know of a better blog/reference for why to use C over C++ today? I'm still writing some of my own stuff in C but honestly I think that's inertia. Freestanding C++ with the exceptions turned off would work fine.

dataflow 4y ago
I don't know of a reference, but C encourages to do more things at run time, whereas C++ encourages you to do more things at compile time. Simplest example of this is probably qsort() vs. std::sort(), but it extends far beyond this. So you end up with slightly slower code in C, but much faster compile times, and much smaller binaries. So if you want smaller binaries or faster compile times, you'll have an easier time keeping them in C. Of course you'll have an easier time keeping & introducing more bugs in C too, but that's another matter.
pjmlp 4y ago
There are only two valid reasons, UNIX/POSIX kernels that naturally will hardly embrace anything else, and embedded toolchains that refuse to embrace modern times.
rramadass 4y ago
>why to use C over C++ today? Simplicity. You can keep the entire language in your head and everything is explicit with no "magic" involved. That said, you might want to start moving to C++ slowly, first as a "better C with user-defined types" and then to OOP/Generic/etc. programming goodness which gives you a much larger design space.
- JonChesterfield 4y ago
  There's pretty much all the same compiler magic either way. At least C++ gives you placement new and std::launder, C gives you malloc and you cross your fingers that the compiler's alias analysis goes your way for now.
- WalterBright 4y ago
  > You can keep the entire language in your head Explain, without looking it up, exactly how macro expansion works. (Don't feel bad. I've written 3 implementations of the CPP, and still couldn't tell you how it works without carefully reading it again.)
  - ndesaulniers 4y ago
    Right, you can "hide" what's going on in otherwise proceedural C codebases w/ the preprocessor. To be more charitable to OP, in C++ you can further "hide" what's going on with destructors in addition to the preprocessor. (I like RAII and hope more C programmers can learn to appreciate it. I have fixed and reviewed many fixes in the Linux kernel for -Wsometime-initialized because error handling using goto is a constant source of programmer mistakes introducing UB). I'd love to chat sometime about approaches to implementing a CPP!
    - int_19h 4y ago
      It's not even that macros can hide complexity. It's that the specification for the C preprocessor is itself rather complicated and non-obvious - e.g. what happens when nesting even simple macros, or even something as basic as tokenization.
      - WalterBright 4y ago
        Right, I was talking about the specification, not the use. How people use the preprocessor is by just fiddling with it till it delivers what they want, then they move on.
- mhh__ 4y ago
  You can keep the language in your head, but there's good empirical evidence you can't keep the code in your (companies collective) head.
sakras 4y ago
I recently started a project in pure C (coming from writing C++ professionally for a few years). I love it. Honestly, the biggest advantage for me is the massive reduction in mental overhead. In C++, every single line introduces something to think about: is this a reference or a value? Does this incur a memory allocation? Is this copy expensive? Has this been moved from? It’s all a huge mess. Contrast with C: none of these problems exist (well, maybe the copy one if the struct is big) I can focus on implementing my design, even if it does take a bit more typing.
- moloch-hai 4y ago
  I spent a few years coding C after using C++. The cognitive load needed to keep code correct was crushing, and switching back to C++ was massively liberating. I didn't code any memory leaks, use-after-frees, or buffer overruns, but the effort to avoid them was ever-present, a continual drag and distraction from what the code was meant to achieve.
  - sakras 4y ago
    I guess it really depends on what your program is doing. In my system, everything I do is linked to how I use my memory and its layout (so much that I don’t use malloc/free, just my own arena allocator), so I wouldn’t be able to avoid thinking about things like this in C++ either. I can see how if you have allocation-heavy code that making them more convenient to use correctly would be nice, but for me “allocation-heavy” is an anti pattern anyway.
    - moloch-hai 4y ago
      Malloc misuse was just the tip of the iceberg, as regards cognitive load that C imposes to maintain correctness. Those are just the most visible.

dataflow 4y ago

I don't know of a reference, but C encourages to do more things at run time, whereas C++ encourages you to do more things at compile time. Simplest example of this is probably qsort() vs. std::sort(), but it extends far beyond this. So you end up with slightly slower code in C, but much faster compile times, and much smaller binaries. So if you want smaller binaries or faster compile times, you'll have an easier time keeping them in C. Of course you'll have an easier time keeping & introducing more bugs in C too, but that's another matter.

pjmlp 4y ago

There are only two valid reasons, UNIX/POSIX kernels that naturally will hardly embrace anything else, and embedded toolchains that refuse to embrace modern times.

rramadass 4y ago

>why to use C over C++ today? Simplicity. You can keep the entire language in your head and everything is explicit with no "magic" involved. That said, you might want to start moving to C++ slowly, first as a "better C with user-defined types" and then to OOP/Generic/etc. programming goodness which gives you a much larger design space.

JonChesterfield 4y ago
There's pretty much all the same compiler magic either way. At least C++ gives you placement new and std::launder, C gives you malloc and you cross your fingers that the compiler's alias analysis goes your way for now.
WalterBright 4y ago
> You can keep the entire language in your head Explain, without looking it up, exactly how macro expansion works. (Don't feel bad. I've written 3 implementations of the CPP, and still couldn't tell you how it works without carefully reading it again.)
- ndesaulniers 4y ago
  Right, you can "hide" what's going on in otherwise proceedural C codebases w/ the preprocessor. To be more charitable to OP, in C++ you can further "hide" what's going on with destructors in addition to the preprocessor. (I like RAII and hope more C programmers can learn to appreciate it. I have fixed and reviewed many fixes in the Linux kernel for -Wsometime-initialized because error handling using goto is a constant source of programmer mistakes introducing UB). I'd love to chat sometime about approaches to implementing a CPP!
  - int_19h 4y ago
    It's not even that macros can hide complexity. It's that the specification for the C preprocessor is itself rather complicated and non-obvious - e.g. what happens when nesting even simple macros, or even something as basic as tokenization.
    - WalterBright 4y ago
      Right, I was talking about the specification, not the use. How people use the preprocessor is by just fiddling with it till it delivers what they want, then they move on.
mhh__ 4y ago
You can keep the language in your head, but there's good empirical evidence you can't keep the code in your (companies collective) head.

sakras 4y ago

I recently started a project in pure C (coming from writing C++ professionally for a few years). I love it. Honestly, the biggest advantage for me is the massive reduction in mental overhead. In C++, every single line introduces something to think about: is this a reference or a value? Does this incur a memory allocation? Is this copy expensive? Has this been moved from? It’s all a huge mess. Contrast with C: none of these problems exist (well, maybe the copy one if the struct is big) I can focus on implementing my design, even if it does take a bit more typing.

moloch-hai 4y ago
I spent a few years coding C after using C++. The cognitive load needed to keep code correct was crushing, and switching back to C++ was massively liberating. I didn't code any memory leaks, use-after-frees, or buffer overruns, but the effort to avoid them was ever-present, a continual drag and distraction from what the code was meant to achieve.
- sakras 4y ago
  I guess it really depends on what your program is doing. In my system, everything I do is linked to how I use my memory and its layout (so much that I don’t use malloc/free, just my own arena allocator), so I wouldn’t be able to avoid thinking about things like this in C++ either. I can see how if you have allocation-heavy code that making them more convenient to use correctly would be nice, but for me “allocation-heavy” is an anti pattern anyway.
  - moloch-hai 4y ago
    Malloc misuse was just the tip of the iceberg, as regards cognitive load that C imposes to maintain correctness. Those are just the most visible.