5 ms·

Most important aspect of C is its portability. From small microcontrollers to almost any computing platform. I doubt that any new version of C will see that muc

Most important aspect of C is its portability. From small microcontrollers to almost any computing platform. I doubt that any new version of C will see that much adoption. If I want to live on cutting edge I would rather use C++2x or Rust rather than C. Am I missing something? What benefit this supposedly modern C offers?

vitaminka 2y ago
these features will eventually trickle down into the mainstream, kind of like C11 is doing at the moment also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today
- bboygravity 2y ago
  Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.
  - dhhfss 2y ago
    This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available. I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20
    - pjmlp 2y ago
      Unless you can vouch for the C++ compiler, the best C++ portable code can offer today is C++17. Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.
      - flohofwoe 2y ago
        SDCC is a niche C compiler for 8-bit CPUs and is more uptodate than MSVC ;P https://sdcc.sourceforge.net/ https://sdcc.sourceforge.net/ That's the nice thing with C: it's much easier for small teams to fully support than the latest C++ standards.
        pjmlp 2y ago
        Now try to use it on the embedded deployments that require certification.
    - bboygravity 2y ago
      Most devices that are 6+ years old (as far as I can tell) use C99. If not C89. And/or C++17, if that. That's A LOT of devices out there. A lot of which still get maintenance and even get feature updates (I'm working on one right now, C99). So the claim that "C codebases generally use C11 or C17, and C++ code bases use C++20" intuitively sounds like totally untrue to someone working in embedded C/C++. I've been doing this for 15+ years and I've never touched anything higher than C99 or C++17. If you're talking about gaming, sure. But that's not "C code bases generally".
  - vitaminka 2y ago
    most non-embedded and non-legacy codebases could use c23, that's not an insignificant set
    - bboygravity 2y ago
      I would argue that is an insignificant set. Unless you think that code-bases created in the past year are a significant part of code bases that have been created since the inception of humanity.
deleted 2y ago
[deleted]
doe_eyes 2y ago
Of course they will, just like they did in the past with C11, GNU extensions, or some of the individual features that are now rolled into C23. For example, the 0b notation for binary numbers is widely used in the MCU world. The microcontroller toolchains are generally built on top of GCC, so they get the features for free. There are some proprietary C compilers that are chronically lagging behind, but they are not nearly as important as they used to be two decades ago.
shakna 2y ago
The `thread_local` specifier is used on a few microcontroller platforms already, but would be absolutely illegal in C11 and before to use. However, it vastly simplifies memory management in a threaded context. Why would I rather step into the world of C++ just to deal with that?
- casenmgreen 2y ago
  IIRC, performance and cost of thread local store varies greatly between platforms. You have to know what you're biting into, before you use that.
flohofwoe 2y ago
One advantage of writing C code is that you don't have annoying discussions about what idiomatic code is supposed to look like, and what language subset is the right one ;) For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust. One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less annoying for us C library maintainers to support the people how want to compile their C code with a C++ compiler.
- pjmlp 2y ago
  There is enough material in C, and related compiler extensions, to have similar discussions, starting from where to place brackets.
  - rbanffy 2y ago
    Maybe the C24 will define the One Right Way.
- Arch-TK 2y ago
  > C library maintainers to support the people how want to compile their C code with a C++ compiler. Just tell them to go away. Trying to write the subset of C and C++ is a fool's errand.
  - jstarks 2y ago
    No inline functions in library headers, then.
    - flohofwoe 2y ago
      Inline is mostly pointless in C anyway though. But it might be a minor problem for STB-style header libraries. It's not uncommon for C++ projects to include the implementation of an STB-style header into a C++ source file instead of 'isolating' them in a C source file. That's about the only reason why I still support the common C/C++ subset in my C libraries.
pragma_x 2y ago
I'm with you on this. The feature list reads like a subset of later C++ standards that fit within C's (deliberately) rudimentary feature set. You could, in theory, just use C++ and be done with it. But like any C++ project you'd need a pretty strict style guide or even a linter, but this time it would have to be extra restrictive lest you slide into full C++ territory. And maybe that's a major stumbling block for some people?
BenjiWiebe 2y ago
Won't any llvm/gcc supported target get the new version of C automatically? You won't get it in the vendor-modified ancient gcc toolchain for some other arch though.
- israrkhan 2y ago
  There are many embedded platforms that do not gcc/llvm based compilers. Also most companies making those platforms are not good at updating their toolchains. Expecting developers to compile their own toolchain, that is unsupported by platform vendor, is too much to ask. Also GCC dropped support for certain architectures along the way, and even if you are willing to compile your own toolchain, it may not work for you.

vitaminka 2y ago

these features will eventually trickle down into the mainstream, kind of like C11 is doing at the moment also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today

bboygravity 2y ago
Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.
- dhhfss 2y ago
  This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available. I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20
  - pjmlp 2y ago
    Unless you can vouch for the C++ compiler, the best C++ portable code can offer today is C++17. Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.
    - flohofwoe 2y ago
      SDCC is a niche C compiler for 8-bit CPUs and is more uptodate than MSVC ;P https://sdcc.sourceforge.net/ https://sdcc.sourceforge.net/ That's the nice thing with C: it's much easier for small teams to fully support than the latest C++ standards.
      - pjmlp 2y ago
        Now try to use it on the embedded deployments that require certification.
  - bboygravity 2y ago
    Most devices that are 6+ years old (as far as I can tell) use C99. If not C89. And/or C++17, if that. That's A LOT of devices out there. A lot of which still get maintenance and even get feature updates (I'm working on one right now, C99). So the claim that "C codebases generally use C11 or C17, and C++ code bases use C++20" intuitively sounds like totally untrue to someone working in embedded C/C++. I've been doing this for 15+ years and I've never touched anything higher than C99 or C++17. If you're talking about gaming, sure. But that's not "C code bases generally".
- vitaminka 2y ago
  most non-embedded and non-legacy codebases could use c23, that's not an insignificant set
  - bboygravity 2y ago
    I would argue that is an insignificant set. Unless you think that code-bases created in the past year are a significant part of code bases that have been created since the inception of humanity.

deleted 2y ago

[deleted]

doe_eyes 2y ago

Of course they will, just like they did in the past with C11, GNU extensions, or some of the individual features that are now rolled into C23. For example, the 0b notation for binary numbers is widely used in the MCU world. The microcontroller toolchains are generally built on top of GCC, so they get the features for free. There are some proprietary C compilers that are chronically lagging behind, but they are not nearly as important as they used to be two decades ago.

shakna 2y ago

The `thread_local` specifier is used on a few microcontroller platforms already, but would be absolutely illegal in C11 and before to use. However, it vastly simplifies memory management in a threaded context. Why would I rather step into the world of C++ just to deal with that?

casenmgreen 2y ago
IIRC, performance and cost of thread local store varies greatly between platforms. You have to know what you're biting into, before you use that.

flohofwoe 2y ago

One advantage of writing C code is that you don't have annoying discussions about what idiomatic code is supposed to look like, and what language subset is the right one ;) For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust. One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less annoying for us C library maintainers to support the people how want to compile their C code with a C++ compiler.

pjmlp 2y ago
There is enough material in C, and related compiler extensions, to have similar discussions, starting from where to place brackets.
- rbanffy 2y ago
  Maybe the C24 will define the One Right Way.
Arch-TK 2y ago
> C library maintainers to support the people how want to compile their C code with a C++ compiler. Just tell them to go away. Trying to write the subset of C and C++ is a fool's errand.
- jstarks 2y ago
  No inline functions in library headers, then.
  - flohofwoe 2y ago
    Inline is mostly pointless in C anyway though. But it might be a minor problem for STB-style header libraries. It's not uncommon for C++ projects to include the implementation of an STB-style header into a C++ source file instead of 'isolating' them in a C source file. That's about the only reason why I still support the common C/C++ subset in my C libraries.

pragma_x 2y ago

I'm with you on this. The feature list reads like a subset of later C++ standards that fit within C's (deliberately) rudimentary feature set. You could, in theory, just use C++ and be done with it. But like any C++ project you'd need a pretty strict style guide or even a linter, but this time it would have to be extra restrictive lest you slide into full C++ territory. And maybe that's a major stumbling block for some people?

BenjiWiebe 2y ago

Won't any llvm/gcc supported target get the new version of C automatically? You won't get it in the vendor-modified ancient gcc toolchain for some other arch though.

israrkhan 2y ago
There are many embedded platforms that do not gcc/llvm based compilers. Also most companies making those platforms are not good at updating their toolchains. Expecting developers to compile their own toolchain, that is unsupported by platform vendor, is too much to ask. Also GCC dropped support for certain architectures along the way, and even if you are willing to compile your own toolchain, it may not work for you.