I'm trying to drag one program at $employer up to C99 (plus C11 _Generic), so I can then subsequently drag it to the bits of C23 which GCC 13 supports.
This all takes times, and having to convince colleagues during code reviews.
What C23 has done is authorise some of the extensions which GCC has had for some time as legitimate things (typeof, etc).
However the ability to adopt is also limited by what third party linters in use at $employer may also support.
Nah - more that a lot of commercial code is written in it; and it doesn't make sense to replace (or rewrite) it at this time.
For example, I'm maintaining some 20 year old C code, which the employer adopted around 10 years ago. It will likely stay in use at least until the current product is replaced, whenever that may be.
Let me rephrase that: I feel myself addressed by "some people will never move beyond C, no matter what" and I prefer C over C++, because it is a much simpler language. Each time I am leaving the cozy world of C and write C++ I am annoyed and miss things.
Well his "Normal Functions" (benchmarks/closures/source/normal_functions.cpp in his repo) looks quite similar to what I had with my GNU nested functions using a stand in "wide pointer", and hence no generated trampoline.
Which rather suggests to me that such a scheme, but generated by the compiler, should have a similar performance to said "Normal Functions" and hence similar to his preferred lambda form.
Since his benchmark environment is so unwieldy, I may have a go at extracting those two code sets to a standalone environment, and measure them so see...
So here are my preliminary benchmarks with my own implementation on an AMD EPYC 9334 32-Core processo. I need to double checks things - so take this with a grain of salt for now. Time is in seconds for 100000 iterations of manorboy(10). So far, the only implementation which clearly sucks is std::function<>. Even trampolines are suprisingly good (but I can imagine that they are much worse on other CPUs / architectures)
All through middle and high school, so for 7 years from around 10 to 16.
It did become one eventually in primary school, so probably the last 2 or 3 years there.
> In 1979 the “standard practice in C of passing a large struct to a function” wasn’t just not standard practice, it didn’t exist!
Yes it did exist. It just wasn't mentioned in the original K&R book.
See this page of a memo from November 78, passing and returning structs was supported. When I learn C on a Unix system, there was a copy of this memo in the printed papers section.
There is a bark of an Englifh tree, which I have found by experience to be a powerful aftringent, and very efficacious in curing aguifh [agues] and intermitting diforders.
My curiofity prompted me to look into the difpenfatories and books of botany, and examine what they faid concerning it; but there it exifted only by name. I could not find, that it hath, or ever had, any place in pharmacy, or any fuch qualities, as I fufpected afcribed to it by the botanifts.
If (as it appears) the author was unable to type in a long-S, he could at least have used a normal one, making the text more readable.
Partially "slamming" where agents would try to get folks to switch to a different billing provider, and get paid a commission. So some fraudulently "sign up" random addresses they were supposed to visit.
The other case has been miscommunication over phone or email to someone actually requesting to change billing provider. Or error on the part of the potential customer.
I've had a bill from some random billing provider. In my case it is common for folks newly arriving in the block of flats to get the digits of the address transposed. Due to them using the common English convention, whereas the part of Scotland I'm in uses a different convention.
The other example of nested functions which you've not mentioned was in Metaware High C.
There they allowed nested functions, but also what they termed "full function values", being a form of fat pointer. Certainly I came across it in High-C v1.7 in 1990, and the full manual for an earlier version (1.2?) from around '85 can be found on Bitsavers.
It had a syntax like:
extern void Quick_sort(
int Lo, int Hi, int Compare(int a, int b)!,
void Swap(int a,int b)!
);
static Sort_private_table() {
Entry Entries[100];
int Compare(int a,int b) {
return Entries[a] < Entries[b];
}
void Swap(int a,int b) {
Entry Temp = Entries[a];
Entries[a] = Entries[b];
Entries[b] = Temp;
}
...
Quick_sort(1,100,Compare,Swap);
}
The above is an extract from their language reference, which you can find here:
Note - as far as I can see, it has similar behaviour to what you propose with _Wide for a wide pointer. Just that it is existing practice, from 40 years ago.
I believe the High-C compiler with this support is still available, for modern embedded CPUs.
I'm trying to drag one program at $employer up to C99 (plus C11 _Generic), so I can then subsequently drag it to the bits of C23 which GCC 13 supports.
This all takes times, and having to convince colleagues during code reviews.
What C23 has done is authorise some of the extensions which GCC has had for some time as legitimate things (typeof, etc).
However the ability to adopt is also limited by what third party linters in use at $employer may also support.
reply