393 lines
12 KiB
Plaintext
393 lines
12 KiB
Plaintext
|
\input texinfo @c -*-texinfo-*-
|
||
|
|
@c %**start of header
|
||
|
|
@setfilename objc-features.info
|
||
|
|
@settitle GNU Objective-C runtime features
|
||
|
|
@setchapternewpage odd
|
||
|
|
@c %**end of header
|
||
|
|
|
||
|
|
@node Top, Executing code before main, , (dir), (dir)
|
||
|
|
@comment node-name, next, previous, up
|
||
|
|
|
||
|
|
@chapter GNU Objective-C runtime features
|
||
|
|
|
||
|
|
This document is meant to describe some of the GNU Objective-C runtime
|
||
|
|
features. It is not intended to teach you Objective-C, there are several
|
||
|
|
resources on the Internet that present the language. Questions and
|
||
|
|
comments about this document to Ovidiu Predescu
|
||
|
|
@code{<ovidiu@@cup.hp.com>}.
|
||
|
|
|
||
|
|
@menu
|
||
|
|
* Executing code before main::
|
||
|
|
* Type encoding::
|
||
|
|
* Garbage Collection::
|
||
|
|
@end menu
|
||
|
|
|
||
|
|
|
||
|
|
@node Executing code before main, What you can and what you cannot do in +load, Top, Top
|
||
|
|
@section @code{+load}: Executing code before main
|
||
|
|
|
||
|
|
|
||
|
|
The GNU Objective-C runtime provides a way that allows you to execute
|
||
|
|
code before the execution of the program enters the @code{main}
|
||
|
|
function. The code is executed on a per-class and a per-category basis,
|
||
|
|
through a special class method @code{+load}.
|
||
|
|
|
||
|
|
This facility is very useful if you want to initialize global variables
|
||
|
|
which can be accessed by the program directly, without sending a message
|
||
|
|
to the class first. The usual way to initialize global variables, in the
|
||
|
|
@code{+initialize} method, might not be useful because
|
||
|
|
@code{+initialize} is only called when the first message is sent to a
|
||
|
|
class object, which in some cases could be too late.
|
||
|
|
|
||
|
|
Suppose for example you have a @code{FileStream} class that declares
|
||
|
|
@code{Stdin}, @code{Stdout} and @code{Stderr} as global variables, like
|
||
|
|
below:
|
||
|
|
|
||
|
|
@example
|
||
|
|
|
||
|
|
FileStream *Stdin = nil;
|
||
|
|
FileStream *Stdout = nil;
|
||
|
|
FileStream *Stderr = nil;
|
||
|
|
|
||
|
|
@@implementation FileStream
|
||
|
|
|
||
|
|
+ (void)initialize
|
||
|
|
@{
|
||
|
|
Stdin = [[FileStream new] initWithFd:0];
|
||
|
|
Stdout = [[FileStream new] initWithFd:1];
|
||
|
|
Stderr = [[FileStream new] initWithFd:2];
|
||
|
|
@}
|
||
|
|
|
||
|
|
/* Other methods here */
|
||
|
|
@@end
|
||
|
|
|
||
|
|
@end example
|
||
|
|
|
||
|
|
In this example, the initialization of @code{Stdin}, @code{Stdout} and
|
||
|
|
@code{Stderr} in @code{+initialize} occurs too late. The programmer can
|
||
|
|
send a message to one of these objects before the variables are actually
|
||
|
|
initialized, thus sending messages to the @code{nil} object. The
|
||
|
|
@code{+initialize} method which actually initializes the global
|
||
|
|
variables is not invoked until the first message is sent to the class
|
||
|
|
object. The solution would require these variables to be initialized
|
||
|
|
just before entering @code{main}.
|
||
|
|
|
||
|
|
The correct solution of the above problem is to use the @code{+load}
|
||
|
|
method instead of @code{+initialize}:
|
||
|
|
|
||
|
|
@example
|
||
|
|
|
||
|
|
@@implementation FileStream
|
||
|
|
|
||
|
|
+ (void)load
|
||
|
|
@{
|
||
|
|
Stdin = [[FileStream new] initWithFd:0];
|
||
|
|
Stdout = [[FileStream new] initWithFd:1];
|
||
|
|
Stderr = [[FileStream new] initWithFd:2];
|
||
|
|
@}
|
||
|
|
|
||
|
|
/* Other methods here */
|
||
|
|
@@end
|
||
|
|
|
||
|
|
@end example
|
||
|
|
|
||
|
|
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, Type encoding, Executing code before main, Executing code before main
|
||
|
|
@subsection What you can and what you cannot do in @code{+load}
|
||
|
|
|
||
|
|
The +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 (@@"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, What you can and what you cannot do in +load, Top
|
||
|
|
@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 bitfields
|
||
|
|
@tab @code{b} followed by the starting position of the bitfield, the type of the bitfield and the size of the bitfield (the bitfields encoding was changed from the NeXT's compiler encoding, see below)
|
||
|
|
@end multitable
|
||
|
|
|
||
|
|
@c @sp 1
|
||
|
|
|
||
|
|
The encoding of bitfields has changed to allow bitfields to be properly
|
||
|
|
handled by the runtime functions that compute sizes and alignments of
|
||
|
|
types that contain bitfields. The previous encoding contained only the
|
||
|
|
size of the bitfield. Using only this information it is not possible to
|
||
|
|
reliably compute the size occupied by the bitfield. 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 bitfield 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 @code{'^'} followed by the pointed type.
|
||
|
|
@item arrays
|
||
|
|
@tab @code{'['} followed by the number of elements in the array followed by the type of the elements followed by @code{']'}
|
||
|
|
@item structures
|
||
|
|
@tab @code{'@{'} followed by the name of the structure (or '?' if the structure is unnamed), the '=' sign, the type of the members and by @code{'@}'}
|
||
|
|
@item unions
|
||
|
|
@tab @code{'('} followed by the name of the structure (or '?' if the union is unnamed), the '=' sign, the type of the members followed by @code{')'}
|
||
|
|
@end multitable
|
||
|
|
|
||
|
|
Here are some types and their encodings, as they are generated by the
|
||
|
|
compiler on a i386 machine:
|
||
|
|
|
||
|
|
@sp 1
|
||
|
|
|
||
|
|
@multitable @columnfractions .25 .75
|
||
|
|
@item Objective-C type
|
||
|
|
@tab Compiler encoding
|
||
|
|
@item
|
||
|
|
@example
|
||
|
|
int a[10];
|
||
|
|
@end example
|
||
|
|
@tab @code{[10i]}
|
||
|
|
@item
|
||
|
|
@example
|
||
|
|
struct @{
|
||
|
|
int i;
|
||
|
|
float f[3];
|
||
|
|
int a:3;
|
||
|
|
int b:2;
|
||
|
|
char c;
|
||
|
|
@}
|
||
|
|
@end example
|
||
|
|
@tab @code{@{?=i[3f]b128i3b131i2c@}}
|
||
|
|
@end multitable
|
||
|
|
|
||
|
|
@sp 1
|
||
|
|
|
||
|
|
In addition to the types the compiler also encodes the type
|
||
|
|
specifiers. The table below describes the encoding of the current
|
||
|
|
Objective-C type specifiers:
|
||
|
|
|
||
|
|
@sp 1
|
||
|
|
|
||
|
|
@multitable @columnfractions .25 .75
|
||
|
|
@item Specifier
|
||
|
|
@tab Encoding
|
||
|
|
@item @code{const}
|
||
|
|
@tab @code{r}
|
||
|
|
@item @code{in}
|
||
|
|
@tab @code{n}
|
||
|
|
@item @code{inout}
|
||
|
|
@tab @code{N}
|
||
|
|
@item @code{out}
|
||
|
|
@tab @code{o}
|
||
|
|
@item @code{bycopy}
|
||
|
|
@tab @code{O}
|
||
|
|
@item @code{oneway}
|
||
|
|
@tab @code{V}
|
||
|
|
@end multitable
|
||
|
|
|
||
|
|
@sp 1
|
||
|
|
|
||
|
|
The type specifiers are encoded just before the type. Unlike types
|
||
|
|
however, the type specifiers are only encoded when they appear in method
|
||
|
|
argument types.
|
||
|
|
|
||
|
|
|
||
|
|
@node Garbage Collection, , Type encoding, Top
|
||
|
|
|
||
|
|
@page
|
||
|
|
@section Garbage Collection
|
||
|
|
|
||
|
|
Support for a new memory management policy has been added by using a
|
||
|
|
powerful conservative garbage collector, known as the
|
||
|
|
Boehm-Demers-Weiser conservative garbage collector. It is available from
|
||
|
|
@w{@uref{http://reality.sgi.com/boehm_mti/gc.html}}.
|
||
|
|
|
||
|
|
To enable the support for it you have to configure the compiler using an
|
||
|
|
additional argument, @w{@kbd{--enable-objc-gc}}. You need to have
|
||
|
|
garbage collector installed before building the compiler. This will
|
||
|
|
build an additional runtime library which has several enhancements to
|
||
|
|
support the garbage collector. The new library has a new name,
|
||
|
|
@kbd{libobjc_gc.a} to not conflict with the non-garbage-collected
|
||
|
|
library.
|
||
|
|
|
||
|
|
When the garbage collector is used, the objects are allocated using the
|
||
|
|
so-called typed memory allocation mechanism available in the
|
||
|
|
Boehm-Demers-Weiser collector. This mode requires precise information on
|
||
|
|
where pointers are located inside objects. This information is computed
|
||
|
|
once per class, immediately after the class has been initialized.
|
||
|
|
|
||
|
|
There is a new runtime function @code{class_ivar_set_gcinvisible()}
|
||
|
|
which can be used to declare a so-called @strong{weak pointer}
|
||
|
|
reference. Such a pointer is basically hidden for the garbage collector;
|
||
|
|
this can be useful in certain situations, especially when you want to
|
||
|
|
keep track of the allocated objects, yet allow them to be
|
||
|
|
collected. This kind of pointers can only be members of objects, you
|
||
|
|
cannot declare a global pointer as a weak reference. Every type which is
|
||
|
|
a pointer type can be declared a weak pointer, including @code{id},
|
||
|
|
@code{Class} and @code{SEL}.
|
||
|
|
|
||
|
|
Here is an example of how to use this feature. Suppose you want to
|
||
|
|
implement a class whose instances hold a weak pointer reference; the
|
||
|
|
following class does this:
|
||
|
|
|
||
|
|
@example
|
||
|
|
|
||
|
|
@@interface WeakPointer : Object
|
||
|
|
@{
|
||
|
|
const void* weakPointer;
|
||
|
|
@}
|
||
|
|
|
||
|
|
- initWithPointer:(const void*)p;
|
||
|
|
- (const void*)weakPointer;
|
||
|
|
@@end
|
||
|
|
|
||
|
|
|
||
|
|
@@implementation WeakPointer
|
||
|
|
|
||
|
|
+ (void)initialize
|
||
|
|
@{
|
||
|
|
class_ivar_set_gcinvisible (self, "weakPointer", YES);
|
||
|
|
@}
|
||
|
|
|
||
|
|
- initWithPointer:(const void*)p
|
||
|
|
@{
|
||
|
|
weakPointer = p;
|
||
|
|
return self;
|
||
|
|
@}
|
||
|
|
|
||
|
|
- (const void*)weakPointer
|
||
|
|
@{
|
||
|
|
return weakPointer;
|
||
|
|
@}
|
||
|
|
|
||
|
|
@@end
|
||
|
|
|
||
|
|
@end example
|
||
|
|
|
||
|
|
Weak pointers are supported through a new type character specifier
|
||
|
|
represented by the @code{'!'} character. The
|
||
|
|
@code{class_ivar_set_gcinvisible()} function adds or removes this
|
||
|
|
specifier to the string type description of the instance variable named
|
||
|
|
as argument.
|
||
|
|
|
||
|
|
|
||
|
|
@bye
|
||
|
|
|