I don’t see anything wrong with grandparent, assuming a particular architecture. And whenever I used to write c, it was almost always for a particular architecture, usually with inlined assembly. Am I missing something, or are you just trying to make some point about portability regarding a metaphor?
It is a lesson hard-learned over many programmer-years of coding that portability should be acquired as an innate reflex; that whenever you are about to sacrifice portability, you ask yourself “Why am I doing so, are there alternatives, and have I done at least a rudimentary cost/benefit analysis of this decision?”
What you don’t do is throw away portability just because you happen to be using a particular machine right now. This is something quickly learned in comp.lang.c.
Incidentally, a better model than PK’s might be:
typedef struct foo {int i} s;
s f;
Now what is ‘f’? Is it an ‘s’, is it a struct foo, or is it an int? And what about f.i? Both have the same address, casting either’s address to any of the pointer types ‘s *’, ‘struct foo *’ or ‘int *’ is valid; writing
*(int *)&f=1;
does just the same as f.i=1; quite possibly the compiler will generate the same code, because after all, the territory is the same. It’s just that “f.i=1” is a higher-level map, which conveniently abstracts things out.
This is made more explicit by considering struct bar {int a; long b;} t; *(long *)(((char *)&bar)+offsetof(bar, b))=1; // same as bar.b=1
Of course, you could go to all the trouble of computing the offset pointer every time, since that’s what happens on the “quark” (assembly language) level of the territory, but the higher-level ‘struct’ map is cognitively useful.
I don’t see anything wrong with grandparent, assuming a particular architecture. And whenever I used to write c, it was almost always for a particular architecture, usually with inlined assembly. Am I missing something, or are you just trying to make some point about portability regarding a metaphor?
It is a lesson hard-learned over many programmer-years of coding that portability should be acquired as an innate reflex; that whenever you are about to sacrifice portability, you ask yourself “Why am I doing so, are there alternatives, and have I done at least a rudimentary cost/benefit analysis of this decision?”
What you don’t do is throw away portability just because you happen to be using a particular machine right now. This is something quickly learned in comp.lang.c.
Incidentally, a better model than PK’s might be:
typedef struct foo {int i} s;
s f;
Now what is ‘f’? Is it an ‘s’, is it a struct foo, or is it an int? And what about f.i? Both have the same address, casting either’s address to any of the pointer types ‘s *’, ‘struct foo *’ or ‘int *’ is valid; writing
*(int *)&f=1;
does just the same as f.i=1; quite possibly the compiler will generate the same code, because after all, the territory is the same. It’s just that “f.i=1” is a higher-level map, which conveniently abstracts things out.
This is made more explicit by considering struct bar {int a; long b;} t; *(long *)(((char *)&bar)+offsetof(bar, b))=1; // same as bar.b=1
Of course, you could go to all the trouble of computing the offset pointer every time, since that’s what happens on the “quark” (assembly language) level of the territory, but the higher-level ‘struct’ map is cognitively useful.