Nat! bio photo

Nat!

Senior Mull

Twitter Github Twitch

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 mulle_objc.

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:

  1. recursively collect all superclass ivars (apply points 2 + 3)
  2. ivars declared within {} in order of appearance

  3. 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.

Name:
E-mail: (not published)
Website: