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.
It’s also upwardly compatible so no messing with code from a deprecated version. Python 2 to python three has this issue. If I need to change my code to make it run on the latest language standard then that is a big red flag for me.
C meeting is over. C23 added:
331–340 of 363 posts
Re: C meeting is over. C23 added:
#332Earlier quoted context omitted.
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.
I'll rather have code that runs on an actual computer than code that should hypothetically run according to a long document that costs 60 dollars to read.
Re: C meeting is over. C23 added:
#333Earlier quoted context omitted.
Right, then comes the day another OS or CPU needs to be supported and some clever developers learn their lesson about language standards during a couple of late nights tracking down production issues.
Seems way more efficient to not care about standards and invest a couple late nights once every five years.
Re: C meeting is over. C23 added:
#334Earlier quoted context omitted.
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.
We, developers, care about standards, because we want to get things done once.
Re: C meeting is over. C23 added:
#335C 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.
Ye the churn is crazy in many languages. I almost had a heart attack when the twitter post stated that "true" and "false" are keywords in C23. However that seems incorrect. On my last workplace we argued if we dared to use stdint.h, since it was so new and fancy. I was a proponent, but there is something calm over discussing whether to use 23 year old additions or not.
Re: C meeting is over. C23 added:
#336C 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.
You could write and rewrite everything multiple times in a high level language with that much work.
C libraries break all the time. They change them whenever they want. The standard lib and language might be stable but the large frameworks aren't.
It doesn't seem at all suitable for large application programs.
I do sometimes worry that one day my Python code won't run and 5 year projects will become useless. But so far, popular language aren't showing any sign of going away.
Re: C meeting is over. C23 added:
#337Earlier quoted context omitted.
C mandates that arrays have positive size. It's not really a discussion about what the target platform does, rather it's what the abstract C machine mandates.
Oh sure - malloc() returns a pointer to sequentially-addressable bytes, not a C array. So even if the size were greater than 0, it would prove nothing about C arrays.
malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.
Re: C meeting is over. C23 added:
#338Earlier 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?
Re: C meeting is over. C23 added:
#339Earlier quoted context omitted.
Access to CPU-specific flags like the carry flag. When doing a multiple-precision addition, if the CPU carry bit is inaccessible, then it must instead be compared to the result to see if it overflowed, which takes 3-5 more instructions per limb or worse on modern superscalar processors that are serial in terms of data accesses.
Portable by definition means it cannot capture every specific detail of every architecture out there.
Re: C meeting is over. C23 added:
#340Earlier quoted context omitted.
Trying to win a pointless argument based on pedantic logic that misses the point.
Usually the typical answer when facts aren't appealing, the other way around apparently being pedantic matters.