I don't mean to criticize. I think the best advice is to read K&R C again. And, as some other posters have suggested, take a look and at least a passing understanding of the memory model and assembly code generated by C/C++ compilers.
You'll see, for instance, that type information is not stored as a field in a C struct at all, it's purely a distinction for the compiler to use. A C struct, indeed any type of data in C, is _just_data_ in memory. At the machine level, there's no such thing as a type. Just registers, memory, and instructions. The compiler uses type information to generate the right instructions to handle the type.
And to clarify, type metadata _as_actual_data_ can exist in higher level languages, but it's definitely not a C thing.
Comments
This is really far off, actually.
I don't mean to criticize. I think the best advice is to read K&R C again. And, as some other posters have suggested, take a look and at least a passing understanding of the memory model and assembly code generated by C/C++ compilers.
You'll see, for instance, that type information is not stored as a field in a C struct at all, it's purely a distinction for the compiler to use. A C struct, indeed any type of data in C, is _just_data_ in memory. At the machine level, there's no such thing as a type. Just registers, memory, and instructions. The compiler uses type information to generate the right instructions to handle the type.
And to clarify, type metadata _as_actual_data_ can exist in higher level languages, but it's definitely not a C thing.
I was speaking of a model of how python does things, based on a C style implementation. Not an explanation of how C works.