I appreciate the distinction between arrays and pointers, but the article fails to mention a similar pitfall: A struct is the sizeof its members., which isn't necessarily true.
It's like how everyone learns that (INT_MAX + 1) == INT_MIN (even non-developers seems to know this) yet that it actually is undefined (in C/C++), I feel that just noting that it isn't the whole truth (such as noting that the OS handles the memory behind your back) is quite valuable, even when learning the basics.
Otherwise you might end up feeling, as I do, that your foundation is shaky and built up on lies - not really knowing what "facts" you can trust.
I went through this learning experience. Something similar to a struct with 32 bit items, a 16 bit item, then a 64 bit item. The 64 bit item was being aligned to a friendly 32 bit address, which left 16 bits of unassigned memory between the 16 and 64 bit items.
Comments
I appreciate the distinction between arrays and pointers, but the article fails to mention a similar pitfall: A struct is the sizeof its members., which isn't necessarily true.
It's like how everyone learns that (INT_MAX + 1) == INT_MIN (even non-developers seems to know this) yet that it actually is undefined (in C/C++), I feel that just noting that it isn't the whole truth (such as noting that the OS handles the memory behind your back) is quite valuable, even when learning the basics.
Otherwise you might end up feeling, as I do, that your foundation is shaky and built up on lies - not really knowing what "facts" you can trust.
I went through this learning experience. Something similar to a struct with 32 bit items, a 16 bit item, then a 64 bit item. The 64 bit item was being aligned to a friendly 32 bit address, which left 16 bits of unassigned memory between the 16 and 64 bit items.