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

91–100 of 363 posts

Re: C meeting is over. C23 added:

#91

Post by leetrout »

mojuba wrote: post #60
dgrunwald wrote: post #54

Earlier quoted context omitted.

What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.

According to the OP tweet though, `foo()` is now a function that takes no arguments.

Agree the tweet makes it seem the behavior is changing.

Edit: parent is correct it IS changing

> We could make this change because foo() decls and definitions had been deprecated since C89/99, longer than I've been alive.

> Implementations will likely warn on foo() decls for a while, and error if someone calls it with foo(too, many, args);.

https://mobile.twitter.com/__phantomderp/status/149481259506...

Re: C meeting is over. C23 added:

#92

Post by pornel »

donkarma wrote: post #75
dureuill wrote: post #61

Earlier quoted context omitted.

You could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment

Rust code takes longer to write than C code

It does for a novice. But once you learn Rust, it's actually quite productive. Rust has proper collections, strings, iterators, automatic (but not GC) memory management, error propagation, etc. This eliminates a lot of busywork, and makes Rust "denser", so you write less code, but get more done.

Re: C meeting is over. C23 added:

#94

Post by qsort »

rwmj wrote: post #48
fulafel wrote: post #35

Earlier quoted context omitted.

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

Some microcontrollers used to have saturating arithmetic, which is basically the only other behavior that makes any sense.

Re: C meeting is over. C23 added:

#95

Post by MaxBarraclough »

rwmj wrote: post #48
fulafel wrote: post #35

Earlier quoted context omitted.

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

> Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

I think such machines are pretty much a thing of the past. This topic cropped up in a 2018 thread when C++ made the same change. [0]

[0] https://news.ycombinator.com/item?id=17190864

Re: C meeting is over. C23 added:

#96

Post by MaxBarraclough »

qsort wrote: post #94
rwmj wrote: post #48

Earlier quoted context omitted.

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

Some microcontrollers used to have saturating arithmetic, which is basically the only other behavior that makes any sense.

Perhaps I'm missing something obvious, but isn't that orthogonal to representation? You could implement saturating arithmetic for any representation scheme, no?

Re: C meeting is over. C23 added:

#97

Post by 10x-dev »

WithinReason wrote: post #85
10x-dev wrote: post #72

Earlier quoted context omitted.

Control over the code that actually runs. We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages. If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't con…

The downside of reordering being performance? Or something else?

Performance is usually the upside. The downside is subtle bugs that can happen due to side effects of the statements being reordered between sequence points.

Re: C meeting is over. C23 added:

#98

Post by pkrumins »

uncomputation wrote: post #31
pkrumins wrote: post #6

Earlier quoted context omitted.

No one cares about the standards. We only care about getting things done by writing regular C code that works.

Huh? What do you think defines “regular C code that works”? Standards. Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.

Only the standards people care about standards. We (programmers) want to just get things done. We don't care about the standards. No one reads the standards. Also no one cares about portability. All computers have been the same for the last 20 years.

Re: C meeting is over. C23 added:

#99

Post by pkrumins »

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

Re: C meeting is over. C23 added:

#100

Post by dig1 »

WithinReason wrote: post #40
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…

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

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 protection marks. If the compiler is really aggressive, it will just put "2" as a constant.

I think that the only benefit of "compiling to C" was reusing existing compilers, not tooling around it. Also, debugging that code is a nightmare unless you are intimate with transpiler internals.

Post reply on HN