(Guess at) Answer = because the record is defined in the header macro which is changed by the pre-processor. That's pretty close. Records are a compile time feature: a record is just a tuple with a special layout, and during compilation all record operations are converted into tuple operations. So given this record definition:
-record(foo, {a, b = default_b}).
#foo{a = x} gets converted to {foo, x, default_b} by the compiler, and a record access such as MyRecord#foo.x becomes something like element(MyRecord, 2) . (except that it also checks that MyRecord is a foo record, and raises a badrecord error otherwise) That's why you can't change the number of elements of a record at runtime: any code that handles such records would need to be recompiled in order to access the right fields. This is similar to how C code needs to be recompiled if you change the layout of a struct.
1条答案
按热度按时间xriantvc1#
(Guess at) Answer = because the record is defined in the header macro which is changed by the pre-processor.
That's pretty close. Records are a compile time feature: a record is just a tuple with a special layout, and during compilation all record operations are converted into tuple operations.
So given this record definition:
#foo{a = x}gets converted to{foo, x, default_b}by the compiler, and a record access such asMyRecord#foo.xbecomes something likeelement(MyRecord, 2). (except that it also checks thatMyRecordis afoorecord, and raises abadrecorderror otherwise)That's why you can't change the number of elements of a record at runtime: any code that handles such records would need to be recompiled in order to access the right fields. This is similar to how C code needs to be recompiled if you change the layout of a struct.