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

61–70 of 360 posts

Re: The C23 edition of Modern C

#61

Post by Conscat »

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"`.

Clang supports C11 - 23 in C++, as well as some future C features like fixed-point integers. The main pain points with Clang are just the fundamental differences like void* and char, which don't typically matter much at an interoperability layer.

Re: The C23 edition of Modern C

#62

Post by layer8 »

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…

The idiomatic

    void strcpy(char *s, char *t)
    {
        while (*s++ = *t++)
            ;
    }
(straight from K&R) wouldn’t work without it.

Re: The C23 edition of Modern C

#63

Post by tialaramex »

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…

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 somehow always meant streaming I/O but his evidence is basically the same library feature he's trying to justify. 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.

The modern fmt-inspired std::print and std::println etc. are much nicer, preserving all the type checking but losing terrible ideas like stored format state, and localisation by default. The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

Re: The C23 edition of Modern C

#64

Post by AlotOfReading »

tjoff wrote: post #35
raluk wrote: post #19

Earlier quoted context omitted.

RAII

The killer feature of RAII is when combined with exceptions. But sneaking in exceptions in an embedded C project isn't something I'd encourage or recommend. C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings. You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it exp…

C++ offers lots of compelling things for embedded use cases, like enum classes (finally fixed in C23), constexpr, std::optional, namespaces, and atomics/generics that are much smaller dumpster fires.

There's an effort to extract the good parts and make it work for embedded use cases or even bring them into C. Khalil Estelle on WG21 has been working on an experimental, deterministic runtime for exception handling, to give one example. Constexpr is an example of the latter that's now showing up in C23.

Re: The C23 edition of Modern C

#65

Post by kccqzy »

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"`.

Yeah plenty of headers first have `#ifdef __cplusplus` and then they add `extern "C"`. And of course even then they have to avoid doing things unacceptable in C++ such as using "new" as the name of a variable.

It takes a little bit of an effort to make a header work on C and C++. A lot less effort than making a single Python file work with Python 2 and 3.

Re: The C23 edition of Modern C

#66

Post by layer8 »

card_zero wrote: post #39
jejdjdbd wrote: post #32

Earlier quoted context omitted.

Why would you use post increment by default? The semantics are very particular. Only on very rare occasions I need post increment semantics. And in those cases I prefer to use a temporary to make the intent more clear

People seem to mostly write a typical for loop ending with ; ++i){ But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics? But I guess this is only a semantic argument.

In C++ the semantics can differ, in that copying an object for post-increment might require a memory allocation internally (for example in the case of a BigInt class), which may fail and throw an exception. For consistency, using pre-increment by default and unless you really need post-increment, is a good habit.

Re: The C23 edition of Modern C

#67

Post by uecker »

int_19h wrote: post #36
f1shy wrote: post #22

Earlier quoted context omitted.

Namespaces is not object orientation, is it? Am I missing something? You can place functions (methods) inside of structs in C23, can't you?

You can handcode vtables in C, just as you can handcode loops in assembly (i.e. it works but it's verbose, not particularly readable, and brings more footguns). But why would you do that if you have an instrument that lets you work at the same level as C, but with methods provided as a proper abstraction that maps exactly to what you'd have written yourself anyway?

I don't know, I never found the "proper abstraction" be more than irrelevant syntactic sugar. And the cost of C++ is that you end up putting everything in the header (IMHO the biggest design flaw of the language) and then compile time start to get long....

Re: The C23 edition of Modern C

#68

Post by layer8 »

WalterBright wrote: post #60
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.

> 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. ;)

Re: The C23 edition of Modern C

#69

Post by uecker »

adamrezich wrote: post #28
f1shy wrote: post #22

Earlier quoted context omitted.

Namespaces is not object orientation, is it? Am I missing something? You can place functions (methods) inside of structs in C23, can't you?

Correct, and you did ask specifically for OO things, but I thought I'd list namespaces too as far as “C++ things you might use when writing C-like C++ code”. Another big one that I always forget C still doesn't support is function overloading.

Function overloading is a feature that makes code less self-documenting without providing any meaningful value. Operator overloading is more interesting, because you can build you domain language with nice syntax. But I also tend to think that this is not really worth it.

Re: The C23 edition of Modern C

#70

Post by kccqzy »

tjoff wrote: post #35
raluk wrote: post #19

Earlier quoted context omitted.

RAII

The killer feature of RAII is when combined with exceptions. But sneaking in exceptions in an embedded C project isn't something I'd encourage or recommend. C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings. You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it exp…

There are a lot of large C++ shops that purposefully disable exceptions and yet still use RAII usefully. It's so useful that in many C codebases you see people using RAII. For example Gtk has g_autoptr and g_autofree.

One of the most compelling things C++ offers to embedded use case is moving runtime initialization to compile-time initialization by liberally using constexpr functions. You literally ask the compiler to do work that would otherwise be done at runtime.

Post reply on HN