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

161–170 of 360 posts

Re: The C23 edition of Modern C

#161

Post by pornel »

jhatemyjob wrote: post #147

Can someone link me to an article that explains why C is basically frozen at C99 for all practical purposes? Few projects worth talking about leverage features from C11 and newer

C99 is still new! Microsoft tried to kill C by refusing to implement anything that wasn't also in C++. MSVC was 16 years late implementing C99, and implemented only the bare minimum. Their C11 implementation is only 11 years late.

I suspect that decades of C being effectively frozen have caused the userbase to self-select to people who like C exactly the way it is (was), and don't mind supporting ancient junk compilers.

Everyone who lost patience, or wanted a 21st century language, has left for C++/Rust/Zig or something else.

Re: The C23 edition of Modern C

#162

Post by Rusky »

layer8 wrote: post #68
WalterBright wrote: post #60

Earlier quoted context omitted.

Modern C still promptly decays an array to a pointer, so no array bounds checking is possible. D does not decay arrays, so D has array bounds checking. Note that array overflow bugs are consistently the #1 problem with shipped C code, by a wide margin.

> no array bounds checking is possible. This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer. The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)

A worked example: https://github.com/pizlonator/llvm-project-deluge/blob/delug...

Re: The C23 edition of Modern C

#163

Post by zabzonk »

wpollock wrote: post #131
card_zero wrote: post #27

Earlier quoted context omitted.

Because people choose to use pre-increment by default instead of post-increment? Why is that?

The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction; they were free. After the PDP-11 went the way of the dodo, both forms took a machine cycle so it (mostly) became a stylistic issue. (The two operators have different semantics, but the trend to avoid side-effects in expressions means that both are most often…

Please explain what you mean by "a separate instruction".

Re: The C23 edition of Modern C

#164

Post by throwaway2037 »

tialaramex wrote: post #63
jasode wrote: post #45

Earlier quoted context omitted.

>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up" Where "mixing C/C++" is helpful: - I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged. - For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf…

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…

Over the years, I have heard numerous complaints about C++ I/O streams. Is there a better open source replacement? Or do you recommend to use C functions for I/O?

Re: The C23 edition of Modern C

#165

Post by zik »

cornstalks wrote: post #160
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? For starters, you have to #include a header to use it.

And it avoids the NULL == 0 ambiguity, allowing for better type checking.

Re: The C23 edition of Modern C

#166

Post by throwaway2037 »

pjmlp wrote: post #132
einpoklum wrote: post #128

Earlier quoted context omitted.

Then I suppose you don't care about: * Performance * Support for localization (as the format string and positions of values to format differ between languages). * Code reuse & dogfooding - the data structures used in iostreams are not used elsewhere, and vice-versa * C and OS interoperability - as you can't wrap a stream around a FILE* / file descritor * bunch of other stuff... iostreams work, but are rather crappy.

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?

Re: The C23 edition of Modern C

#167

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

#168

Post by mmphosis »

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

Re: The C23 edition of Modern C

#169

Post by throwaway2037 »

com2kid wrote: post #143
f1shy wrote: post #14

Earlier quoted context omitted.

What would be an example of "simple OO here and there" that cannot be done cleanly in plain C?

You can do anything in C that you want to. Of course one can make v-tables and all of that, and even do inheritance. But having the "class" keyword is nice. Having built in support for member functions is nice. Sometimes a person just wants the simplicity of C++ 2003. (In reality I was working on a project where our compiler only supported C++ 2003 and we had a UI library written in C++ 2003 and honestly pure C UI li…

    > You can do anything in C that you want to.
How about destructors?

Re: The C23 edition of Modern C

#170

Post by israrkhan »

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?

Post reply on HN