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

191–200 of 363 posts

Re: C meeting is over. C23 added:

#191

Post by zabzonk »

sys_64738 wrote: post #126
dig1 wrote: post #100

Earlier quoted context omitted.

Depending on transpiler (compilers that will compile to C), you can get near representation in C (rarely) or something completely different (frequently). In Scheme/LISP world (where transpilers were popular for a while), even a simple expression like "(+ 1 1)" will rarely give you something like: "int a = 1 + 1;". I've seen these things would produce dozen of lines of various boxing/unboxing calls, type checks and GC…

A compiler that translates to another language used to be called a translator.

All compilers covert programs in one language (say C) into another, (say assembler or machine code), and they are called compilers. The whole transpiler thing is a bit bogus, but a C compiler has never IME been called a translator.

Re: C meeting is over. C23 added:

#192

Post by zabzonk »

pjmlp wrote: post #160
rwmj wrote: post #50

Earlier quoted context omitted.

One of the criteria is "excellent debugging support" which you don't get with transpiled languages, since you'll be buried in generated code when you open the debugger.

Languages like Eiffel prove this isn't the case, it is a matter of proper debug tooling.

Of course, Eiffel is such a popular and widely used language, with a great toolset. /s

Re: C meeting is over. C23 added:

#193

Post by TingPing »

raptorfactor wrote: post #49
WithinReason wrote: post #40

Earlier quoted context omitted.

Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?

Having never used such a language, I'm curious, what's the debugging experience like? Can I source level step the application in the original language or do I have to debug the generated C?

It is always a pain to debug transpiled C IME.

Re: C meeting is over. C23 added:

#194

Post by plorkyeran »

mojuba wrote: post #45

Removing K&R style function prototypes though is kind of big. I remember when one of the Objective-C upgrades started enforcing K&R. I don't think ObjC will be upgraded to C23 (ever, as it's a language being deprecated now I presume) so it will be stuck with K&R... while the rest will move on? Could someone also explain what this means for pure C in terms of compatibility? If there's void foo(); would the meaning of…

Obj-C can be compiled using any version of C (and Obj-C++ can be compiled using any version of C++). You already can use C2x with obj-c if you desire. I don't know what "enforcing K&R" means in this context, but if you think that Obj-C requires using K&R-style function definitions you're very confused about something.

Re: C meeting is over. C23 added:

#195

Post by dzaima »

kaba0 wrote: post #186
dzaima wrote: post #107

Earlier quoted context omitted.

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)

linked lists - true, but at least when you write them you'll be certain of what they do, and, coupled with knowledge of cache performance, precisely how bad they are. About reallocation I don't even mean the copying, but just the code needing to check for the chance overflow on every push. Besides the obvious waste of instructions to check for that, it also clobbers registers even if the branch isn't taken, and thus will easily result in a lot more unnecessary spilling to the stack. This kind of pointless thing happens in a ton of data structures.

Re: C meeting is over. C23 added:

#196

Post by coldtea »

moralestapia wrote: post #180
pjmlp wrote: post #174

Earlier quoted context omitted.

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

Well, then, you must know it's not really a big deal to write code with proper memory checks.

If you think that, then you really don't get C - not as in "it's intents", but as in its actual history and repurcursions...

Re: C meeting is over. C23 added:

#197

Post by coldtea »

nec4b wrote: post #182
pjmlp wrote: post #174

Earlier quoted context omitted.

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.

And he was right. He didn't mean it as a statement of fact (which would be wrong, and he already knew it).

Re: C meeting is over. C23 added:

#198

Post by enedil »

c-linkage wrote: post #132
beeforpork wrote: post #116

> Support for calling realloc() with zero size (the behavior becomes undefined) OMG! Please do not add more undefined behaviour! We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can…

They'd better not convert that to undefined behavior! First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal. Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the valu…

Manual says

> If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().

So it's not really an array of bytes of size 0.

Re: C meeting is over. C23 added:

#199

Post by shakna »

pjmlp wrote: post #171
shakna wrote: post #33

Earlier quoted context omitted.

How many of your preferred programming languages are written in C? Yes, many self-host, but a considerable number of them don't want the complications that can bring.

Modern C compilers are written in C++. So much for C's simplicity in writing compilers.

Yes, C can be simple for writing a compiler. [0][1]

No, optimisation, on the other hand, is not a simple problem.

[0] https://github.com/rui314/8cc

[1] https://github.com/rui314/chibicc

Post reply on HN