6 ms·

Yeah, stopped reading after that. How wrong does he want to be? It is hard to tell what the point is of this article is. Yes, the C-ish subset of C++ differs f

Yeah, stopped reading after that. How wrong does he want to be? It is hard to tell what the point is of this article is. Yes, the C-ish subset of C++ differs from ISO C, in trivial details. That is irrelevant to C++ users, who may consult ISO C++ to discover the actual subset. They interact with any C only when they #include a header for a 3rd party C library, and then the relevant subset is what, exactly, appears in that header. There is really no legitimate reason to code C anymore: A C++ compiler is available for any modern development target. Confining yourself to any C subset (with or without ISO C marginalia) amounts to crawling when you can fly. To be more specific: nothing that can be done using C is unavailable to the C++ coder, but enormous power is available to the C++ coder and wholly unavailable in C.

jstimpfle 4y ago
For me the legitimate reason to code C is to get stuff done, period. There is hardly a need for more (to do what I do -- systems in the broadest sense) and there's a lot of time saved by not thinking about 21 "safe" and "ergonomic" ways to write everything in C++ (that very often end up being not that safe, and unintelligible). Yes, there is the "subset" argument, only use what you need. But I don't buy that, I'm not like that, it doesn't work for me. Constraining myself makes things easier.
- glowingly 4y ago
  This somewhat mirrors my own development. I started in C, and am still in it for systems/OS development at work. In UI development, we had older C toolkits, but are replacing them with newer toolkits that are C++. I started off trying to just do C business logic with some C++ glue code for the UI. Sticking to what's familiar. In the end, it was just easier to do everything properly. All C in areas that are C. All C++ in areas that are C++. Same with C#. Trying to mix them is just more work than necessary. At least I get to add C++ to my resume. There is a little joke at work, w.r.t. our existing codebases and code choices. They are career-driven choices, not technical choices. The result is a mess of a codebase, but I'm fully embracing that now.
- RcouF1uZ4gsC 4y ago
  > For me the legitimate reason to code C is to get stuff done, period. If I want to just get stuff done, C++ is great for that. Don’t underestimate how much you gain by having string, vector, and map when you just want to crank out code. Nobody is forcing you to overdesign stuff. You can always just crank out the code you want.
  - dkersten 4y ago
    Yeah, just having the standard library container types (or similar generic third party libraries if you don’t like std ones, eg I tend to use phmap maps and sets instead of std::unordered_map/set). Templated containers just make using them so much easier than generic containers in C. Ergonomics matter when you just want to get things done. Plus the C++ containers make it easier to manage memory IMHO. The main reason I still sometimes use C is compiler support for microcontrollers where everything tends to have a C compiler but not everything has a C++ one (or if it does, not necessarily an up to date one). I don’t use either in my day to day really but I do have sone personal projects. Ultimately I foresee doing these in Rust where I can, but for stuff like hobbyist game development, I’m currently too bought into some of the C++ libraries, primarily EnTT, but even there I think I’ll eventually just end up using Rust with Bevy. For now though, I actually quite enjoy using C++17 (and maybe 20 soon if I find the free time).
    - pjmlp 4y ago
      Even something like Turbo C++ for MS-DOS is preferable to raw C, the only embedded toolchains that don't offer even that are usually stuff like PIC and similar. Which, in any case, have companies like Mikroe selling Basic and Pascal compilers.
KingLancelot 4y ago
[dead]
saghm 4y ago
> There is really no legitimate reason to code C anymore: A C++ compiler is available for any modern development target. Confining yourself to any C subset (with or without ISO C marginalia) amounts to crawling when you can fly. > > To be more specific: nothing that can be done using C is unavailable to the C++ coder, but enormous power is available to the C++ coder and wholly unavailable in C. As a counterargument, sometimes constraints can be valuable in their own right rather than just being requirements for some larger goal. The most prominent example of this in programming design is type checking; enforcing type checking at compile time strictly reduces the number of programs you can express, so dynamic languages can do everything that static languages and more, and yet it turns out that it's still pretty useful specifically because we sometimes want to avoid the programs that a dynamic language would allow but a static language would reject. At the risk of getting too philosophical, imagine framing programming as an exercise in trying to write rules to specify one program out of the set of all possible programs, where each bug you write that changes the semantics moves one step further from your goal. The compiler can act as a "filter" on the set of programs you can potentially select by refusing to process your rules if they would specify one of the forbidden programs, which reduces the chance selecting the wrong program by mistake. In this scenario, the theoretically ideal compiler would be the one that rejects all programs other than the exact one you want! This obviously isn't possible in the general case, but the point here is that as long as compilers don't reject the exact program you want, a compiler that rejects more programs is _more_ useful. I'm not making any claim about whether it is in fact worth it to code C anymore, but I disagree with the logic that C++ letting you do anything C can do and more is proof that C++ should always be used over C. Maybe C is crawling compared to C++'s flying, but if my goal is to get a pen that falls under my desk, it's a lot more useful for me to not use an airplane to do it.
- moloch-hai 4y ago
  Getting your pen doesn't demand enormous power, but you are not obliged to field any, either way. We generally don't know, when we set out, how much support we will be able to benefit from, down the road.
  - galangalalgol 4y ago
tejohnso 4y ago
> There is really no legitimate reason to code C anymore That's an interesting statement. Reminds me of statements indicating any new code base should be started in rust over c++.
- pjmlp 4y ago
  The rewrite in C++ movement was lived in Usenet flamewars, and we were in good path with all the userspace C++ frameworks in OS/2, MS-DOS, Windows, Apple and BeOS until the GNU Manifesto came around and urged everyone to write FOSS code in C. "Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C." GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12 http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12
  - moloch-hai 4y ago
    Stuff written about C++ before there was an ISO Standard obviously does not apply after. And, we should know by now how much Richard Stallman's prejudices are worth.
    - pjmlp 4y ago
      By all means, GNU Coding standards from 2006, 8 years after C++98. "When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program. C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C. So in general it is much better to use C, rather than the comparable alternatives." http://gnu.ist.utl.pt/prep/standards/html_node/Source-Language.html#Source-Language http://gnu.ist.utl.pt/prep/standards/html_node/Source-Langua... As project lead, his opinions always mattered for what goes into GNU. What the rustaceans are doing nowadays I lived as C++ fanboy, so I am pretty aware how things went. Remember that besides the license issue, another big reason why GNOME came to be was because KDE uses C++, hence the whole GObject stuff in C.
phoehne 4y ago
Anyone who says C is not important hasn't worked on embedded systems or operating systems. I work on embedded systems. There are roughly 3 choices for languages[1]. C, Ada, and C++. Except the version of C++ is sometimes often vendor specific and may lack features that are "standard C++", and never have a "full" STL. In addition, if you're not super careful with C++, what you thought was a copy or declaration can execute additional constructor or assignment logic. It might just interfere with your estimate of how long something can take (which is super important in interrupt handlers), or worst case, smash your stack (which can be as small as 1-2k). With C, you pretty much know what's going to happen and what's getting called. The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++. I also spend time debugging compiled, optimized code by tracing instructions. This is hard enough in C, where I don't magically jump to a constructor function or an assignment function. I can visualize in my head how the C code could look like, given the instructions the optimizer produced. So it may not look like my code, but it is a version of the code that I can at least logically infer. Ada is nice, but outside of some super-safety critical realms, it hasn't had the uptake. Private industry prefers not having to make the investment and the government let everyone waive out of it. 1. I know people are going to to say 'what about Rust, Go, or embedded something or other?' They are not as mature in their development lifecycle. So there's no validated RTOS for Rust (there are some experimental ones). Go is even further behind. Basically, you need a vendor supported RTOS that's validated for the safety and operational requirements of your use case, before you can be a serious choice for a lot of embedded work.
- moloch-hai 4y ago
  If you are using vendors' proprietary compilers in place of Gcc, it is purely masochism.
  - Jtsummers 4y ago
    Vendor compilers are common, if not typical, for embedded and safety-critical systems. It's not masochism since they work, and in my experience they work quickly to address any compiler bugs you may discover and report. This is also true for Ada, C++, and Fortran in that domain.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

jstimpfle 4y ago

For me the legitimate reason to code C is to get stuff done, period. There is hardly a need for more (to do what I do -- systems in the broadest sense) and there's a lot of time saved by not thinking about 21 "safe" and "ergonomic" ways to write everything in C++ (that very often end up being not that safe, and unintelligible). Yes, there is the "subset" argument, only use what you need. But I don't buy that, I'm not like that, it doesn't work for me. Constraining myself makes things easier.

glowingly 4y ago
This somewhat mirrors my own development. I started in C, and am still in it for systems/OS development at work. In UI development, we had older C toolkits, but are replacing them with newer toolkits that are C++. I started off trying to just do C business logic with some C++ glue code for the UI. Sticking to what's familiar. In the end, it was just easier to do everything properly. All C in areas that are C. All C++ in areas that are C++. Same with C#. Trying to mix them is just more work than necessary. At least I get to add C++ to my resume. There is a little joke at work, w.r.t. our existing codebases and code choices. They are career-driven choices, not technical choices. The result is a mess of a codebase, but I'm fully embracing that now.
RcouF1uZ4gsC 4y ago
> For me the legitimate reason to code C is to get stuff done, period. If I want to just get stuff done, C++ is great for that. Don’t underestimate how much you gain by having string, vector, and map when you just want to crank out code. Nobody is forcing you to overdesign stuff. You can always just crank out the code you want.
- dkersten 4y ago
  Yeah, just having the standard library container types (or similar generic third party libraries if you don’t like std ones, eg I tend to use phmap maps and sets instead of std::unordered_map/set). Templated containers just make using them so much easier than generic containers in C. Ergonomics matter when you just want to get things done. Plus the C++ containers make it easier to manage memory IMHO. The main reason I still sometimes use C is compiler support for microcontrollers where everything tends to have a C compiler but not everything has a C++ one (or if it does, not necessarily an up to date one). I don’t use either in my day to day really but I do have sone personal projects. Ultimately I foresee doing these in Rust where I can, but for stuff like hobbyist game development, I’m currently too bought into some of the C++ libraries, primarily EnTT, but even there I think I’ll eventually just end up using Rust with Bevy. For now though, I actually quite enjoy using C++17 (and maybe 20 soon if I find the free time).
  - pjmlp 4y ago
    Even something like Turbo C++ for MS-DOS is preferable to raw C, the only embedded toolchains that don't offer even that are usually stuff like PIC and similar. Which, in any case, have companies like Mikroe selling Basic and Pascal compilers.

KingLancelot 4y ago

[dead]

saghm 4y ago

> There is really no legitimate reason to code C anymore: A C++ compiler is available for any modern development target. Confining yourself to any C subset (with or without ISO C marginalia) amounts to crawling when you can fly. > > To be more specific: nothing that can be done using C is unavailable to the C++ coder, but enormous power is available to the C++ coder and wholly unavailable in C. As a counterargument, sometimes constraints can be valuable in their own right rather than just being requirements for some larger goal. The most prominent example of this in programming design is type checking; enforcing type checking at compile time strictly reduces the number of programs you can express, so dynamic languages can do everything that static languages and more, and yet it turns out that it's still pretty useful specifically because we sometimes want to avoid the programs that a dynamic language would allow but a static language would reject. At the risk of getting too philosophical, imagine framing programming as an exercise in trying to write rules to specify one program out of the set of all possible programs, where each bug you write that changes the semantics moves one step further from your goal. The compiler can act as a "filter" on the set of programs you can potentially select by refusing to process your rules if they would specify one of the forbidden programs, which reduces the chance selecting the wrong program by mistake. In this scenario, the theoretically ideal compiler would be the one that rejects all programs other than the exact one you want! This obviously isn't possible in the general case, but the point here is that as long as compilers don't reject the exact program you want, a compiler that rejects more programs is _more_ useful. I'm not making any claim about whether it is in fact worth it to code C anymore, but I disagree with the logic that C++ letting you do anything C can do and more is proof that C++ should always be used over C. Maybe C is crawling compared to C++'s flying, but if my goal is to get a pen that falls under my desk, it's a lot more useful for me to not use an airplane to do it.

moloch-hai 4y ago
Getting your pen doesn't demand enormous power, but you are not obliged to field any, either way. We generally don't know, when we set out, how much support we will be able to benefit from, down the road.
- galangalalgol 4y ago

tejohnso 4y ago

> There is really no legitimate reason to code C anymore That's an interesting statement. Reminds me of statements indicating any new code base should be started in rust over c++.

pjmlp 4y ago
The rewrite in C++ movement was lived in Usenet flamewars, and we were in good path with all the userspace C++ frameworks in OS/2, MS-DOS, Windows, Apple and BeOS until the GNU Manifesto came around and urged everyone to write FOSS code in C. "Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C." GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12 http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12
- moloch-hai 4y ago
  Stuff written about C++ before there was an ISO Standard obviously does not apply after. And, we should know by now how much Richard Stallman's prejudices are worth.
  - pjmlp 4y ago
    By all means, GNU Coding standards from 2006, 8 years after C++98. "When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program. C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C. So in general it is much better to use C, rather than the comparable alternatives." http://gnu.ist.utl.pt/prep/standards/html_node/Source-Language.html#Source-Language http://gnu.ist.utl.pt/prep/standards/html_node/Source-Langua... As project lead, his opinions always mattered for what goes into GNU. What the rustaceans are doing nowadays I lived as C++ fanboy, so I am pretty aware how things went. Remember that besides the license issue, another big reason why GNOME came to be was because KDE uses C++, hence the whole GObject stuff in C.

phoehne 4y ago

Anyone who says C is not important hasn't worked on embedded systems or operating systems. I work on embedded systems. There are roughly 3 choices for languages[1]. C, Ada, and C++. Except the version of C++ is sometimes often vendor specific and may lack features that are "standard C++", and never have a "full" STL. In addition, if you're not super careful with C++, what you thought was a copy or declaration can execute additional constructor or assignment logic. It might just interfere with your estimate of how long something can take (which is super important in interrupt handlers), or worst case, smash your stack (which can be as small as 1-2k). With C, you pretty much know what's going to happen and what's getting called. The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++. I also spend time debugging compiled, optimized code by tracing instructions. This is hard enough in C, where I don't magically jump to a constructor function or an assignment function. I can visualize in my head how the C code could look like, given the instructions the optimizer produced. So it may not look like my code, but it is a version of the code that I can at least logically infer. Ada is nice, but outside of some super-safety critical realms, it hasn't had the uptake. Private industry prefers not having to make the investment and the government let everyone waive out of it. 1. I know people are going to to say 'what about Rust, Go, or embedded something or other?' They are not as mature in their development lifecycle. So there's no validated RTOS for Rust (there are some experimental ones). Go is even further behind. Basically, you need a vendor supported RTOS that's validated for the safety and operational requirements of your use case, before you can be a serious choice for a lot of embedded work.

moloch-hai 4y ago
If you are using vendors' proprietary compilers in place of Gcc, it is purely masochism.
- Jtsummers 4y ago
  Vendor compilers are common, if not typical, for embedded and safety-critical systems. It's not masochism since they work, and in my experience they work quickly to address any compiler bugs you may discover and report. This is also true for Ada, C++, and Fortran in that domain.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]