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

271–280 of 360 posts

Re: The C23 edition of Modern C

#271

Post by eqvinox »

pm215 wrote: post #269
eqvinox wrote: post #265

Earlier quoted context omitted.

Uh, why so serious? I called it "a bit of a stretch ;D" - there was a reason for that smiley. I'm well aware BE is alive enough to be around. If you can't live without knowing, sure, my stake in dismissing big endian architectures is that I can't in fact dismiss BE architectures because I have users on it. And it's incredibly painful to test because while my users have such hardware, actually buying a good test platf…

To be fair to IBM, with s390x they do have a "community cloud" programme where open source projects can apply to get a Linux s390x VM to use for things like CI: https://community.ibm.com/zsystems/l1cc/ . But yeah, BE MIPS is super awkward because the target systems are all embedded things that are bad dev/CI machines.

Stupidly enough, "my" software is a routing control plane (FRRouting), so what I need to support are exactly those embedded things. I'm not sure anyone uses FRRouting on a s390x machine. But maybe we should go ask IBM anyway, a BE system is a BE system…

qemu CPU emulation exists too, but that's painfully slow for an actual CI run, and I'm not sure I trust it enough with e.g. AF_NETLINK translation to use the "-user" variant on top of an LE host rather than booting a full Linux (or even BSD).

And in the very best case, proper testing would pit BE and LE systems "against" each other; if I run tests on BE against itself there's a good risk of mis-encodings on send being mis-decoded back on receive and thus not showing as breakage…

… really, it's just a pain to deal with. Even the beauty (in my eyes) of these T4240 ppc64 systems doesn't bridge that :(

Re: The C23 edition of Modern C

#272

Post by tjoff »

Ragnarork wrote: post #266
tjoff wrote: post #116

Earlier quoted context omitted.

If you argue for Rust I'm all for it, arguably much less of a learning curve than C++ too.

Strong disagree on that one. Even though C++ has a lot of features that take a while to learn, getting started with C++ is simpler by miles than getting started with Rust. One exception to that in my experience: dependencies, although I think that's a bit deceiving as yes, it's easier to get dependencies in Rust but in some areas they're way less mature and can sometimes be a pain to work with (usually when dealing w…

Agree, writing bad C++ is easy. But being competent in C++ requires much more than being competent in rust.

And not being competent in C++ is not great. You are going to be much more productive in C. The feedback loop is much faster, that is, feedback from your designs.

Contrast with Rust which is harder to get going but doesn't require nearly as much to be decent.

Re: The C23 edition of Modern C

#273

Post by uvas_pasas_per »

I've been using modern C++ for a personal project (a language interpreter) for the last year+. I constantly think of switching to C, because of the mental burdens of C++, and because of the problems with tooling (Visual Studio's IntelliSense still barely works, because I use C++20 modules), and compile times get ugly because of the way the language failures force so much into interfaces (even with modules). But on the flip side I've gotten so used to classes, member functions, generic programming (templates), namespaces... I may be hooked.

Re: The C23 edition of Modern C

#274

Post by johnisgood »

dhhfss wrote: post #193
johnisgood wrote: post #186

Earlier quoted context omitted.

Well, I always include stdio.h which includes stddef.h that defines NULL as (void *)0.

In my experience, hardly any source files require studio.h stddef.h on the other hand is required by most to get size_t

You are right. Hereby I correct my parent comment: I talked about my own personal experience[1], but yeah, as you said, stddef.h is often required (and yes, often I do not need stdio.h, stddef.h is what I need) which defines NULL, which was my point. If it is often required, then it does not matter whether you have to include a header file or not, IMO.

Just include the stddef.h header if you want to use NULL, similarly to how you include a header file if you want to use anything else, e.g. bool from stdbool.h.

[1] I am not entirely sure in retrospect, actually, as I might be misremembering, but my point stands with or without stdio.h!

Re: The C23 edition of Modern C

#275

Post by pjmlp »

flohofwoe wrote: post #246
pjmlp wrote: post #215

Earlier quoted context omitted.

Unless you can vouch for the C++ compiler, the best C++ portable code can offer today is C++17. Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.

SDCC is a niche C compiler for 8-bit CPUs and is more uptodate than MSVC ;P https://sdcc.sourceforge.net/ That's the nice thing with C: it's much easier for small teams to fully support than the latest C++ standards.

Now try to use it on the embedded deployments that require certification.

Re: The C23 edition of Modern C

#276

Post by pjmlp »

uecker wrote: post #240
pjmlp wrote: post #217

Earlier quoted context omitted.

Now try that on a compiler without -fsanitize=bounds, yet full ISO C compliant.

You can still access the size which is what the parent was asking for. And please tell me how you would try this on an ISO compliant compiler for D.

D has bounds checking, and isn't a ISO language.

Re: The C23 edition of Modern C

#277

Post by johnisgood »

josefx wrote: post #270
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?) The old definition did not even specify wether it was a pointer or an integer. So for platforms that did not follow the Posix ((void*)0) requirement it was a foot gun that had neither the type nor the size of a pointer. > On top of that "constexpr" and "nullptr" just reeks of C++. Probably because they where back ported from C++. You can still use NULL, since that was apparently redefined…

What platforms are those that are in use, and how widespread their use is?

Re: The C23 edition of Modern C

#278

Post by xbar »

zkirill wrote: post #29

I was going to ask if there is a good list of C books and then answered my own question. It categorizes _Modern C_ as Intermediate level. https://stackoverflow.com/questions/562303/the-definitive-c-...

I like Modern C. I have reviewed it favorably in several places. I agree it is intermediate.

I think 21st Century C by Ben Klemens and C Programming a Modern Approach by King are both more approachable alternatives as a modern C companions to K&R.

Re: The C23 edition of Modern C

#279

Post by kragen »

chithanh wrote: post #237
kragen wrote: post #182

Earlier quoted context omitted.

Microsoft didn't create C23 and they don't <3 FOSS. They're accepting that they have to deal with FOSS, but installing Windows will still make your Linux system unbootable until you fix it with a rescue disk, among numerous other unfriendly things they do.

> installing Windows will still make your Linux system unbootable until you fix it with a rescue disk This is no longer true. On UEFI systems the only thing you have to do normally is fix the boot order. In fact installing Linux first and Windows second tends to be the better dual-boot strategy nowadays. Fixing the boot order can be done from UEFI setup, and even from Windows command line bcdedit /enum firmware bcded…

Thank you for the correction and the howto! How long have I been wrong about this?

Re: The C23 edition of Modern C

#280

Post by vitaut »

spacechild1 wrote: post #148
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…

Remember that C++ originally didn't have variadic templates, so something like std::format would have been impossible back in the day. Back in the day, std::iostream was a very neat solution for type safe string formatting. As you conceded, it also makes it very easy to integrate your own types. It was a big improvement over printf(). Historic perspective is everything.

{fmt} used to support pre-C++11 compilers that didn't have variadic templates. It was a pain to emulate variadics but it wasn't impossible.
Post reply on HN