The C23 edition of Modern C • Hacker News Board

Re: The C23 edition of Modern C

#51

Post by accelbred » Tue, Oct 15, 2024, 6:52 PM UTC

jasode wrote: post #45

belter wrote: post #2

Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

>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…

C++ can seamlessly include C89 headers.

The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++.

Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

Re: The C23 edition of Modern C

#52

Post by accelbred » Tue, Oct 15, 2024, 6:55 PM UTC

bitbasher wrote: post #3

Really looking forward to #embed, once the compilers catch up. Until then, Golang.

I end up using a .S asm file with .incbin directives to embed files.

#embed would be much nicer

Re: The C23 edition of Modern C

#53

Post by racingmars » Tue, Oct 15, 2024, 6:57 PM UTC

zerr wrote: post #48

Do they still use 0-terminated strings/char* as the main string type? Is the usage of single linked lists still prevalent as the main container type?

> Do they still use 0-terminated strings/char* as the main string type?

Of course, it's still C.

> Is the usage of single linked lists still prevalent as the main container type?

As far as I can remember, the C standard library has never had any functions that used linked lists. Nor are there any container types, linked lists or otherwise, provided by C. So I'd say this is a question about how people teach and use C, not related to the language -- or language spec version -- itself.

Re: The C23 edition of Modern C

#54

Post by cozzyd » Tue, Oct 15, 2024, 6:58 PM UTC

tialaramex wrote: post #40

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?

Why use this operator? Like most C and C++ features the main reason tends to be showing off, you learned a thing (in this case that there are four extra operators here) and so you show off by using it even if it doesn't make the software easier to understand. This is not one of those beginner -> journeyman -> expert cycles where coincidentally the way you wrote it as a beginner is identical to how an expert writes it…

It's more useful for pointers than for values, IMO

Re: The C23 edition of Modern C

#55

Post by nuancebydefault » Tue, Oct 15, 2024, 7:03 PM UTC

accelbred wrote: post #51

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…

C++ can seamlessly include C89 headers. The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++. Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

Extern "C" around the prototypes is mandatory, otherwise your linker will search for C++ symbols, which cannot be found in the C libraries you pass it.

Re: The C23 edition of Modern C

#56

Post by AlotOfReading » Tue, Oct 15, 2024, 7:03 PM UTC

rdtsc wrote: post #43

flohofwoe wrote: post #23

Earlier quoted context omitted.

Funny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

That thing always baffled me, this huge company building a professional IDE couldn't figure out how to ship updates to the C compiler. > it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++. I mean, yeah if it came from a two member…

Funnily enough, the intellisense parser does support C syntax because it's using a commercial frontend by edison under the hood. MSVC's frontend doesn't.

Re: The C23 edition of Modern C

#57

Post by runevault » Tue, Oct 15, 2024, 7:05 PM UTC

f1shy wrote: post #20

raluk wrote: post #19

Earlier quoted context omitted.

RAII

Is RAII Object orientation? I thought it was an idiom of C++ by Stroustrup.

It doesn't necessarily have to be OO no. Rust uses RAII and it uses traits instead of traditional OO style inheritance etc. You do need something like destructors/drop trait for it to work as far as I know though.

Re: The C23 edition of Modern C

#58

Post by cozzyd » Tue, Oct 15, 2024, 7:05 PM UTC

f1shy wrote: post #14

com2kid wrote: post #11

Earlier quoted context omitted.

Perfectly valid to do if you need to interface with a large C code base and you just want to do some simple OO here and there. Especially if you cannot have runtime exceptions and the like. This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.

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

CRTP?

Re: The C23 edition of Modern C

#59

Post by renox » Tue, Oct 15, 2024, 7:11 PM UTC

ralphc wrote: post #41

How does "Modern" C compare safety-wise to Rust or Zig?

You'd be surprised: Zig has one UB (Undefined Behaviour) that C doesn't have!

In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in C it wraps.

:-)

Of course C has many UBs that Zig doesn't have, so C is far less safe than Zig, especially since you can use ReleaseSafe in Zig..

Re: The C23 edition of Modern C

#60

Post by WalterBright » Tue, Oct 15, 2024, 7:18 PM UTC

ralphc wrote: post #41

How does "Modern" C compare safety-wise to Rust or Zig?

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.