The @code{+load} is a method that is not overridden by categories. If a
class and a category of it both implement @code{+load}, both methods are
invoked. This allows some additional initializations to be performed in
a category.
This mechanism is not intended to be a replacement for @code{+initialize}.
You should be aware of its limitations when you decide to use it
instead of @code{+initialize}.
@menu
* What you can and what you cannot do in +load::
@end menu
@node What you can and what you cannot do in +load, , Executing code before main, Executing code before main
@subsection What you can and what you cannot do in @code{+load}
The @code{+load} implementation in the GNU runtime guarantees you the following
things:
@itemize @bullet
@item
you can write whatever C code you like;
@item
you can send messages to Objective-C constant strings (@code{@@"this is a
constant string"});
@item
you can allocate and send messages to objects whose class is implemented
in the same file;
@item
the @code{+load} implementation of all super classes of a class are executed before the @code{+load} of that class is executed;
@item
the @code{+load} implementation of a class is executed before the
@code{+load} implementation of any category.
@end itemize
In particular, the following things, even if they can work in a
particular case, are not guaranteed:
@itemize @bullet
@item
allocation of or sending messages to arbitrary objects;
@item
allocation of or sending messages to objects whose classes have a
category implemented in the same file;
@end itemize
You should make no assumptions about receiving @code{+load} in sibling
classes when you write @code{+load} of a class. The order in which
sibling classes receive @code{+load} is not guaranteed.
The order in which @code{+load} and @code{+initialize} are called could
be problematic if this matters. If you don't allocate objects inside
@code{+load}, it is guaranteed that @code{+load} is called before
@code{+initialize}. If you create an object inside @code{+load} the
@code{+initialize} method of object's class is invoked even if
@code{+load} was not invoked. Note if you explicitly call @code{+load}
on a class, @code{+initialize} will be called first. To avoid possible
problems try to implement only one of these methods.
The @code{+load} method is also invoked when a bundle is dynamically
loaded into your running program. This happens automatically without any
intervening operation from you. When you write bundles and you need to
write @code{+load} you can safely create and send messages to objects whose
classes already exist in the running program. The same restrictions as
above apply to classes defined in bundle.
@node Type encoding, Garbage Collection, Executing code before main, Objective-C
@section Type encoding
The Objective-C compiler generates type encodings for all the
types. These type encodings are used at runtime to find out information
about selectors and methods and about objects and classes.
The types are encoded in the following way:
@c @sp 1
@multitable @columnfractions .25 .75
@item @code{char}
@tab @code{c}
@item @code{unsigned char}
@tab @code{C}
@item @code{short}
@tab @code{s}
@item @code{unsigned short}
@tab @code{S}
@item @code{int}
@tab @code{i}
@item @code{unsigned int}
@tab @code{I}
@item @code{long}
@tab @code{l}
@item @code{unsigned long}
@tab @code{L}
@item @code{long long}
@tab @code{q}
@item @code{unsigned long long}
@tab @code{Q}
@item @code{float}
@tab @code{f}
@item @code{double}
@tab @code{d}
@item @code{void}
@tab @code{v}
@item @code{id}
@tab @code{@@}
@item @code{Class}
@tab @code{#}
@item @code{SEL}
@tab @code{:}
@item @code{char*}
@tab @code{*}
@item unknown type
@tab @code{?}
@item bit-fields
@tab @code{b} followed by the starting position of the bit-field, the type of the bit-field and the size of the bit-field (the bit-fields encoding was changed from the NeXT's compiler encoding, see below)
@end multitable
@c @sp 1
The encoding of bit-fields has changed to allow bit-fields to be properly
handled by the runtime functions that compute sizes and alignments of
types that contain bit-fields. The previous encoding contained only the
size of the bit-field. Using only this information it is not possible to
reliably compute the size occupied by the bit-field. This is very
important in the presence of the Boehm's garbage collector because the
objects are allocated using the typed memory facility available in this
collector. The typed memory allocation requires information about where
the pointers are located inside the object.
The position in the bit-field is the position, counting in bits, of the
bit closest to the beginning of the structure.
The non-atomic types are encoded as follows:
@c @sp 1
@multitable @columnfractions .2 .8
@item pointers
@tab @samp{^} followed by the pointed type.
@item arrays
@tab @samp{[} followed by the number of elements in the array followed by the type of the elements followed by @samp{]}
@item structures
@tab @samp{@{} followed by the name of the structure (or @samp{?} if the structure is unnamed), the @samp{=} sign, the type of the members and by @samp{@}}
@item unions
@tab @samp{(} followed by the name of the structure (or @samp{?} if the union is unnamed), the @samp{=} sign, the type of the members followed by @samp{)}
@end multitable
Here are some types and their encodings, as they are generated by the
