141–150 of 363 posts
Why does it even matter? I could take true and false to be an improvement (having them as macros expanding to int literals had its problems, but even for that one I would not mind _True and _False at all), but the rest? Who cares? It’s literally the least significant change.
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…
Are you going to mix all those languages into one project and somehow use their advantages but steer away from their disadvantages? Sure, other languages have caught up or have improved on some of the features where C shines. Let's remove portability and integration from the feature list, because that's strongly related to C's tenure. Which one of the languages you listed matches the rest of the feature set I brought…
So true and false keywords are the only thing that has been added, or am I missing a part of this thread? Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf
The linked tweet is the 4th in a sequence. If you scroll up you should see 3 more tweets with more info.
https://twitter.com/__phantomderp/status/1494801365297676293
> 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?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm#ex...
Earlier quoted context omitted.
One change per decade is not a change.
More than once per decade: C11, C17, C23
So we have C89, C99, C11, and C2X (C23?) as the only revisions introducing new stuff...
Earlier quoted context omitted.
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.
The eventual rust code+debug+maintain speed will be higher than the equivalent C speed, for the same reason.
This means that rust is slower for vanity projects that won't be used in practice, or for low quality products with an attitude a la hack it- ship it - hide for customers - start next mess. The scary part: this is actually an existing corner of our market.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
I'm so glad that you have linked this article from Chisnall. I can now ask you in what ways is the abstract model of a machine on which assembly language operates on, different from the one on which the C language operates on? This is the claim which started this thread: >>C is a portable alternative to assembly language.
C's abstract machine is leaky and full of surprises when UB comes into play for one. Second when people talk about C being portable Assembly, they mistakenly assume to know what comes out of the compiler's backend. Third, unless we are speaking about PDP-11 like CPUs, modern CPUs have tons of capabilities not exposed to ISO C. Finally, since 1958 there are portable alternatives to Assembly in systems programming with…
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.
> [dropped] Representations for signed integers other than two's complement May I assume that there won't be signed int undefined behavior after C23? INT_MAX + 1 == INT_MIN?
I doubt it, and wouldn’t want it. It would break all kinds of optimizations. For example, with wrapping for(int i = 0; i Wouldn’t terminate if m = INT_MAX . That means compilers either have to special-case that value, or can’t use the loop instructions of some CPUs (M68000 has “decrement and branch if larger than zero”, for example) Also, with wrapping, a[i] and a[i+1] aren’t guaranteed to be adjacent. That can make…
For example, with wrapping
for(int i = 0; i Earlier quoted context omitted.
Perhaps I'm missing something obvious, but isn't that orthogonal to representation? You could implement saturating arithmetic for any representation scheme, no?
You can only observe whether the representation is 2s-complement or not if you can see what wrapping does.
Overflow of signed integer types remains undefined behaviour in both C and C++. A compiler is free to make a promise like signed integer overflow is always handled with wrapping or signed integer overflow is always handled with saturation. (GCC has a flag, -fwrapv, to enable guaranteed wrapping. [1])
[0] https://stackoverflow.com/a/25664954/
[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html