Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

171–180 of 360 posts

Re: The C23 edition of Modern C

#171

Post by vitaminka »

israrkhan wrote: post #170

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?

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

Re: The C23 edition of Modern C

#173

Post by PaulDavisThe1st »

Dwedit wrote: post #109
pjmlp wrote: post #80

Earlier quoted context omitted.

Perfectly iostreams happy user since 1993.

int a; cin >> a; Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped. Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.

   fscanf (STDIN, "%d", &a);
the program goes beserk as soon as the first non-number is read out of standard input.

in both cases, you need error checking (which you "know about").

Re: The C23 edition of Modern C

#174

Post by [deleted] »

israrkhan wrote: post #170

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?

[deleted]

Re: The C23 edition of Modern C

#175

Post by PaulDavisThe1st »

throwaway2037 wrote: post #166
pjmlp wrote: post #132

Earlier quoted context omitted.

I care about performance, when it actually matters to acceptance testing. The less C the merrier. If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

> If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with. What do you recommend instead?

_("some text") ... aka gettext and friends.

Re: The C23 edition of Modern C

#176

Post by PaulDavisThe1st »

wakawaka28 wrote: post #140
tialaramex wrote: post #63

Earlier quoted context omitted.

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

>No other language does this, and it's not because they can't it's because it was a bad idea when it was created, it was still a bad idea in 1998, the only difference today is that C++ has a replacement. Hindsight is 20/20, remember that. Streams are not that bad of an idea and have been working fine for decades. You haven't named a problem with it other than the fact the operators are used for other stuff in other c…

What they mean is this:

     struct Foo {
       int a;
       float b;
       std::string c;
     };


     Foo foo;
     std::cout
with no extra code. It's called reflection, where the compiler can generate good-enough code to generate a character-stream serialization of an object without any human intervention.

Re: The C23 edition of Modern C

#177

Post by [deleted] »

mmphosis wrote: post #168
johnisgood wrote: post #156

Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…

NULL is not wrong. The things that I will do with NULL are

[deleted]

Re: The C23 edition of Modern C

#178

Post by [deleted] »

johnisgood wrote: post #156

Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…

[deleted]

Re: The C23 edition of Modern C

#179

Post by nickelpro »

johnisgood wrote: post #156

Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…

> what is wrong with NULL?

One of the few advantages of ISO standardization is you can just read the associated papers to answer questions like this: https://wg21.link/p2312

The quick bullet points:

* Surprises when invoking a type-generic macro with a NULL argument.

* Conditional expressions such as (1 ? 0 : NULL) and (1 ? 1 : NULL) have different status depending how NULL is defined

* A NULL argument that is passed to a va_arg function that expects a pointer can have severe consequences. On many architectures nowadays int and void* have different size, and so if NULL is just 0, a wrongly sized argument is passed to the function.

Re: The C23 edition of Modern C

#180

Post by doe_eyes »

israrkhan wrote: post #170

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?

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.

Post reply on HN