mulle_objc: ivar layout with @property
Continued from mulle-objc: the trouble with @property
As explained in the previous entry: to support @property I made the decision that every property of a class must have a related ivar.
To support @defs and some more obscure variations of @encode, it becomes necessary to specify at @interface time, in what order the ivars will be generated.
properties declared in classes
These properties always auto-synthesize an ivar as described in the previous entry.
properties declared in categories
These properties do NOT have a related ivar, they also do not get synthesized. You must write the accessor code yourself. These are the only true “dynamic” properties without ivar backing in .
properties declared in protocols
A protocol property needs to be reimplemented by the class or category. By itself it does not produce any ivars or code. You do not need to repeat the @property declaration, if you supply the appropriately named ivar.
Example:
@protocol Foo
@property long value;
@end
@interface Foo <Foo>
{
long _value;
}
@end
but you can also just copy the @property line:
@protocol Foo
@property long value;
@end
@interface Foo <Foo>
@property long value;
@end
Memory Layout
The mulle-objc compiler does not sort the synthesized instance variables of properties by size (as clang usually does). Instead synthesized ivars are appended in the order of their respective @property declarations.
The layout is done as follows:
- recursively collect all superclass ivars (apply points 2 + 3)
-
ivars declared within
{}
in order of appearance - ivars synthesized by properties in order of appearance
Example
@interface Bar
{
int _a;
}
@property char b;
@property int c;
@end
@interface Foo : Bar
{
char _d;
}
@property int e;
@property char d; // ivar specified
@end
the ivar layout for Bar will be
position | name | type ———+——–+——-+ #0 | _a | int #1 | _b | int #2 | _c | char
the ivar layout for Foo will be
position | name | type ———+——–+——-+ #0 | _a | int #1 | _b | int #2 | _c | char #3 | _d | char #4 | _e | int
Continue to mulle_objc: root objects and unloadable runtimes.
Post a comment
All comments are held for moderation; basic HTML formatting accepted.