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

81–90 of 360 posts

Re: The C23 edition of Modern C

#81

Post by lugu »

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…

Thank you.

Re: The C23 edition of Modern C

#82

Post by ahoka »

uecker wrote: post #72
renox wrote: post #59

Earlier quoted context omitted.

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

UB is does not automatically make things unsafe. You can have a compiler that implements safe defaults for most UB, and then it is not unsafe.

By definition UB cannot be safe.

Re: The C23 edition of Modern C

#83

Post by pjmlp »

enriquto wrote: post #9
bitbasher wrote: post #3

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

This is not how C standards work. If it appears in the standard, it means that it is already implemented in some compilers (in that case, at least in gcc and clang).

That isn't really how it goes, that is how it used to be up to C99.

Re: The C23 edition of Modern C

#85

Post by enriquto »

pjmlp wrote: post #83
enriquto wrote: post #9

Earlier quoted context omitted.

This is not how C standards work. If it appears in the standard, it means that it is already implemented in some compilers (in that case, at least in gcc and clang).

That isn't really how it goes, that is how it used to be up to C99.

Thanks for the correction! Do you know if there is a document from the standards body explaining the change in philosophy?

Re: The C23 edition of Modern C

#86

Post by AlotOfReading »

tjoff wrote: post #73
AlotOfReading wrote: post #64

Earlier quoted context omitted.

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…

I don't disagree, but these are in the ~2% convenience at most. With the huge baggage of including C++ in a project. The cost of learning C++ easily outweighs all those benefits. If you happen to have a proficient C++ team (that actually know embedded), go for it!

Speaking more broadly than just the std implementation, but result types like optional shouldn't be a 2% convenience, they should be used in most function calls that return errors. Rust is the obvious example here.

Re: The C23 edition of Modern C

#87

Post by secondcoming »

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.

It makes no difference if the increment is done on an int, but it can make a different if your `i` is some object with its own ++ operator.

Re: The C23 edition of Modern C

#88

Post by [deleted] »

f1shy wrote: post #15
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"

A couple of months ago, in the company I work, there was a talk from HR, where they explained how to make a good CV (the company is firing lots of people). She say: "if you have experience in programming C, you can writing just that, or, if you have lots of experience in C, is customary to write ``C++ Experience'' " Sooo... yeah... I should definitely change company!

[deleted]

Re: The C23 edition of Modern C

#89

Post by secondcoming »

renox wrote: post #59
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..

Does C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.

Re: The C23 edition of Modern C

#90

Post by kanbankaren »

Quekid5 wrote: post #75
card_zero wrote: post #39

Earlier quoted context omitted.

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.

I've seen either style, but it the argument about which is proper is pointless. Any modern compiler will optimize either equally well, unless you're doing something that actually depends on the order of the increment.

No, for fundamental datatypes pre/post-increment doesn't matter, but for classes that overload those operators, the postfix form creates a temporary object hence people write

for(auto it = begin(v); it != end(v); ++it)

Post reply on HN