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

231–240 of 360 posts

Re: The C23 edition of Modern C

#231

Post by varjag »

thenipper wrote: post #112
f1shy wrote: post #15

Earlier quoted context omitted.

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!

How many pluses until you should just say you have D experience?

Possibly three. Four pluses is naturally C#.

Re: The C23 edition of Modern C

#232

Post by sim7c00 »

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"

can't believe so many people are arguing against this honestly. you don't mix them in the sense the author means. I take it these people didn't read the paragraphs this was the 'takeaway' from.

For example, the primary reason for the sentence seems to be from the text: "Many code examples in this book won't even compile on a c++ compiler, So we should not mix sources of both languages".

It's not at all about the ability to use c libraries in c++ projects or vice versa :S.... c'mon guys!

Re: The C23 edition of Modern C

#233

Post by humanrebar »

flohofwoe wrote: post #204
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…

auto is mostly useful when tinkering with type-generic macros, but shouldn't be used in regular code (e.g. please no 'almost always auto' madness like it was popular in the C++ world for a little while). Unfortunately there are also slight differences between compilers (IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those dif…

> IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those differences have been fixed in the meantime

Both have compatibly implemented the standard C++ auto. Since 2011 or so.

Re: The C23 edition of Modern C

#234

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

#235

Post by casenmgreen »

shakna wrote: post #189
israrkhan wrote: post #170

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?

The `thread_local` specifier is used on a few microcontroller platforms already, but would be absolutely illegal in C11 and before to use. However, it vastly simplifies memory management in a threaded context. Why would I rather step into the world of C++ just to deal with that?

IIRC, performance and cost of thread local store varies greatly between platforms.

You have to know what you're biting into, before you use that.

Re: The C23 edition of Modern C

#236

Post by worksonmine »

pornel wrote: post #229
purple-leafy wrote: post #192

Earlier quoted context omitted.

Skill issue

It's been a skill issue for 40 years. How long are we going to continue searching for those programmers who don't make mistakes?

Programmers make stupid mistakes in the safest languages too, even more so today when software is a career and not a hobby. What does it matter if the memory allocation is safe when the programmer exposes all user sessions to the internet because reading Dockers' documentation is too much work? Even Github did a variant of this with all their resources.

Re: The C23 edition of Modern C

#237

Post by chithanh »

kragen wrote: post #182
rdtsc wrote: post #95

Earlier quoted context omitted.

> It was on purpose, Microsoft was done with C Indeed, and yet here we are with C23 > The change of heart was the new management, and the whole Microsoft Yeah, agree. To me the turning point was when they created WSL.

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
  bcdedit /set {fwbootmgr} displayorder {yourlinuxuuid} /addfirst
(Put single quotes around {} if you use PowerShell instead of CMD.exe)

Re: The C23 edition of Modern C

#238

Post by sylware »

I am worried where "official" C is going. Its syntax which is already too complex and already does too much, but that would require to "break" backward compatibility namely it would require "porting". But since it would be still "C" that amount of work should be close to "a bit" of "step by step" refactoring

For instance, only sized types:u8...s64, f32, f64... no implicit casts except for void* and literals, no integer promotion, no switch, no enum, only one loop keyword (loop{}!), no anonymous code block, and no toxic attribute like "packed structure" which makes us lose sight of data alignment... no _generic, typeof, restrict, syntax based tls, etc...

But we would need explicit atomics, explicit memory barriers, explicit unaligned memory access.

Instead of adding and complexifying C to make writing a naive compiler more and more complex, long and a mouse and cat catchup "to the standard" tedious task, what should be done is exactly the other way around.

In end, I don't trust C officials anymore, I tend to stick to C99, or even assembly (I am currently writing rv64 assembly I run an x86_64).

Re: The C23 edition of Modern C

#239

Post by flohofwoe »

humanrebar wrote: post #233
flohofwoe wrote: post #204

Earlier quoted context omitted.

auto is mostly useful when tinkering with type-generic macros, but shouldn't be used in regular code (e.g. please no 'almost always auto' madness like it was popular in the C++ world for a little while). Unfortunately there are also slight differences between compilers (IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those dif…

> IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those differences have been fixed in the meantime Both have compatibly implemented the standard C++ auto. Since 2011 or so.

Well, not in C :)

Here's an example where Clang and GCC don't agree about the behaviour of auto in C23:

https://www.godbolt.org/z/WchMK18vx

IIRC Clang implements 'C++ semantics' for C23 auto, while GCC doesn't.

Last time I brought that up it turned out that both behaviours are 'standard compliant', because the C23 standard explicitly allows such differing behaviour (it basically standardized the status quo even if different compilers disagreed about auto semantics in C).

PS: at least Clang has a warning now in pedantic mode: https://www.godbolt.org/z/ovj5r4axn

Re: The C23 edition of Modern C

#240

Post by uecker »

pjmlp wrote: post #217
uecker wrote: post #210

Earlier quoted context omitted.

Oh, it also work for runtime length: https://godbolt.org/z/PnaWWcK9o

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.
Post reply on HN