121–130 of 178 posts
Earlier quoted context omitted.
The reason the asterisk naturally "sticks to" the name is simply the possibility to write a series of declarations like this: int a, *b, (*c)(int);
Which is a questionable saving of 2 lines and a few characters in a language where huge repetitions are a given, due to lack of templates/generics whatever.
IMO, pointers are less difficult to comprehend than other abstractions, like lambdas are. If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory. Anyway, many more ana…
C's pointers aren't memory addresses. Ok, they tend to be represented as such at run time, but that's not what the spec actually says the are. And as far as compiler authors are concerned, they can do anything they want as long as it's within spec. Further, the spec even requires some additional behaviors pure memory addresses aren't capable of. See https://www.ralfj.de/blog/2020/12/14/provenance.html for examples of the extra requirements.
Compared to that mess, lambdas are trivial. They're just functions.
There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.
I wasn't sure anyone but the authors remembered C Unleashed! I wrote the chapter on binary search trees and balanced trees. Comp.lang.c was important to me for many years. I've met 5 or so of the regulars at least once. The most famous comp.lang.c regular is probably Tim Hockin of the Kubernetes project.
Jens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.
What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?
There was a "C Unleashed" book, a massive tome of 1000+ pages written by many famous programmers, many of them who where quite active in comp.lang.c, like Richard Heathfield and CB Falconer, had quite insightful material in it. Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.
Earlier quoted context omitted.
I don't disagree with that, but most cases fall within a pretty clear pattern: - typedef struct { ... } foo - foo *foo_create() - void foo_destroy(foo *) - a bunch of functions that take foo* as their first arg which is kind of the same as a class and only more error-prone. I say this as someone who actually _likes_ C, but the manual memory management model is very often unnecessary, confusing, repetitive. There was…
I’m actually implementing that right now for my own use, as a pre-processor. There is a much more advanced design and implementation at “A defer mechanism for C” (December 2020): https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f... For my own purposes, I think I can live without handling stack unwinding so I continue working on my pre-processor. Since the pre-processor is not yet finished, there I use a ve…
Jens Gustedt's "Modern C" ( https://modernc.gforge.inria.fr ) is an excellent resource as well.
What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?
There's fair amount added to the core since C89, actually... And if you include the library changes, game over! I had no idea how much had been added.
More challenging is to find what's been subtracted.
This no longer defaults to int:
static i;
And gets() is toast.
Anyone know any others?
Earlier quoted context omitted.
What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?
I'm chuckling to myself at "there are not many new language features" because that's what I thought. There's fair amount added to the core since C89, actually... And if you include the library changes, game over! I had no idea how much had been added. More challenging is to find what's been subtracted. This no longer defaults to int: static i; And gets() is toast. Anyone know any others?
Earlier quoted context omitted.
I wasn't sure anyone but the authors remembered C Unleashed! I wrote the chapter on binary search trees and balanced trees. Comp.lang.c was important to me for many years. I've met 5 or so of the regulars at least once. The most famous comp.lang.c regular is probably Tim Hockin of the Kubernetes project.
Ben Pfaff... There's a name I recognize from back then. :-)
> When compiling C,machine codeis generated. This is the 1s and 0s that can be executed directly by the CPU.
No! Tell me about how the code is translated into an ELF executable, linked, has its memory laid out by the OS and then executed.
> I’m seriously oversimplifying how modern memory works, here. But the mental model works, so please forgive me
No! Tell me about how memory works in the C abstract machine which is what you can actually program against and guaranteed by the compiler.
> Nothing of yours gets called before main(). In the case of our example, this works fine since all we want to do is print a line and exit
No! tell that main is special because it's mapped to the _start symbol or at least eventually jumped into by code at that symbol which has an address that's stored by the linker in e_entry.
Like I might be the weird one but this kind of writing (which is common to seemingly all C texts) confuses me more than if it had just been explained.