Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

181–190 of 363 posts

Re: C meeting is over. C23 added:

#181

Post by nec4b »

pjmlp wrote: post #167
nec4b wrote: post #148

Earlier quoted context omitted.

You haven't answered the question? Maybe because is there is no concernable difference between abstract machine models of both languages? You can't do anything more about instruction reordering or cache invalidation at the CPU level with assembly than you can with C.

You surely can, better read those CPU manuals about line bus controllers.

Have you? I used to write device drivers mostly on ARM architectures and I have newer seen an instruction which would let me precisely control CPU instruction ordering or what it does with cache that I couldn't do in C.

Re: C meeting is over. C23 added:

#182

Post by nec4b »

pjmlp wrote: post #174
moralestapia wrote: post #158

Earlier quoted context omitted.

>Maybe in another 60 it will get proper strings and arrays. If you think this is missing, there's a big chance you don't "get" C. Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.

I surely get C, having to deal with its casualties in DevSecOps. I have been "getting" C since 1992, across Xenix, DG/UX, HP-UX, Solaris, AIX, FreeBSD, Linux, Amiga, Windows 3.x,.....

You once claimed C requires UNIX like OS to run.

Re: C meeting is over. C23 added:

#183

Post by moralestapia »

kaba0 wrote: post #64
10x-dev wrote: post #32

Earlier quoted context omitted.

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…

C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer t…

>due to C not having good expressive/abstracting powers

I disagree, if anything, C's scantness forces you to abstract things much properly, unless you plan to write pages of boilerplate code here and there.

Re: C meeting is over. C23 added:

#184

Post by mhh__ »

moralestapia wrote: post #158
pjmlp wrote: post #153

Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.

>Maybe in another 60 it will get proper strings and arrays. If you think this is missing, there's a big chance you don't "get" C. Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues.

Of course, you can emulate these yourself, it's just a struct but not everyone does.

Re: C meeting is over. C23 added:

#185

Post by mhh__ »

sgt wrote: post #37

Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?

D is a better modern C than Rust.

Rust is very nice, but if you just want a safer C that will actually make you more productive versus less productive until you understand how rust wants you to program then D is a better fit.

Re: C meeting is over. C23 added:

#186

Post by kaba0 »

dzaima wrote: post #107
kaba0 wrote: post #64

Earlier quoted context omitted.

C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer t…

In C it's possible (and, to some level, very much encouraged) to write your own things to replace whatever built in thing you don't like for whatever reason, be it speed, size, portability. C not having fancy built-in structures means programmers are more careful about choosing simple ones, which dramatically cuts down the amount of completely pointless generated code. -O3 can optimize registers and maybe memory read…

> C not having fancy built-in structures means programmers are more careful about choosing simple ones

Resulting in linked lists everywhere which have pretty terrible performance characteristics. You should be worried about those way before the occasional vector push reallocation cause you any problem. (And you can specify initial capacity so there is that)

Re: C meeting is over. C23 added:

#187

Post by rossy »

sys_64738 wrote: post #124

Does anybody bother about the stuff after C99?

MSVC just got C11 support a little over a year ago, so you won't see many big cross-platform projects using it yet, unfortunately. Some projects can optionally use C11 stdatomic.h and stdalign.h to replace old OS and compiler-specific extensions, but most of them still keep fallback code in case C11 isn't available.

Re: C meeting is over. C23 added:

#188

Post by notreallyserio »

wartijn_ wrote: post #66
rwmj wrote: post #25

Earlier quoted context omitted.

Thanks - Twitter UI is terrible. I'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.

This is off topic, but I don't think the problem is just that the Twitter is terrible. If you want to link to a thread, you should click on the first tweet of that thread and copy its url. It's easy to see the rest of the thread: just scroll down. If you want to link to one tweet in a thread you should click on that tweet and copy its url. The person who posted the link to HN did the latter, while they should have do…

While we're off topic here's my little rant about Twitter "threads":

It's easy to see all of the tweets made by the author, at least those made as replies to themselves, but reading the actual threads is hard or impossible. At least I haven't figured out how to do it despite considerable effort.

For example, say you want to view the replies to the tweet above the linked tweet, the one about "assert". There are supposedly 4 replies. If you tap that tweet you remain in the same list of self-replied tweets. There are replies at the end, but are they replies to the tweet you want to focus on? It doesn't look like it, but who knows, maybe? It's even worse on linger Twitter self-reply "threads".

I don't know how Twitter's engineers got the well-established threading pattern so wrong. This behavior doesn't even increase the number of ads you see.

Re: C meeting is over. C23 added:

#189

Post by [deleted] »

RcouF1uZ4gsC wrote: post #133

> typeof(...) is standard I thought C++11 went with decltype because typeof was implemented by compilers as an extension with various subtle semantic differences than what they wanted. I wonder why the C committee went with typeof instead of decltype?

[deleted]

Re: C meeting is over. C23 added:

#190

Post by rossy »

pjmlp wrote: post #27
rwmj wrote: post #26

Earlier quoted context omitted.

Sure, I'm certainly not arguing that C is a good language. In RHEL we turn all warnings on, compile everything with hardening flags, use valgrind during development, and feed everything through Coverity.

The exception that confirms the rule.

The exception? It's standard practice for distros to compile with hardening flags, and if RH submits the bugs they find with Coverity upstream, that protects the 1000s of C projects they package.
Post reply on HN