Next: Language Independent Options, Previous: C++ Dialect Options, Up: Invoking GCC
(NOTE: This manual does not describe the Objective-C and Objective-C++ languages themselves. See See Language Standards Supported by GCC, for references.)
This section describes the command-line options that are only meaningful
for Objective-C and Objective-C++ programs, but you can also use most of
the language-independent GNU compiler options.
For example, you might compile a file some_class.m
like this:
gcc -g -fgnu-runtime -O -c some_class.m
In this example, -fgnu-runtime is an option meant only for Objective-C and Objective-C++ programs; you can use the other options with any language supported by GCC.
Note that since Objective-C is an extension of the C language, Objective-C compilations may also use options specific to the C front-end (e.g., -Wtraditional). Similarly, Objective-C++ compilations may use C++-specific options (e.g., -Wabi).
Here is a list of options that are only for compiling Objective-C and Objective-C++ programs:
-fconstant-string-class=
class-name@"..."
. The default
class name is NXConstantString
if the GNU runtime is being used, and
NSConstantString
if the NeXT runtime is being used (see below). The
-fconstant-cfstrings option, if also present, will override the
-fconstant-string-class setting and cause @"..."
literals
to be laid out as constant CoreFoundation strings.
-fgnu-runtime
-fnext-runtime
__NEXT_RUNTIME__
is predefined if (and only if) this option is
used.
-fno-nil-receivers
[receiver message:arg]
) in this translation unit ensure that the receiver
is not nil
. This allows for more efficient entry points in the runtime
to be used. Currently, this option is only available in conjunction with
the NeXT runtime on Mac OS X 10.3 and later.
-fobjc-call-cxx-cdtors
- (id) .cxx_construct
instance method that will run
non-trivial default constructors on any such instance variables, in order,
and then return self
. Similarly, check if any instance variable
is a C++ object with a non-trivial destructor, and if so, synthesize a
special - (void) .cxx_destruct
method that will run
all such default destructors, in reverse order.
The - (id) .cxx_construct
and/or - (void) .cxx_destruct
methods
thusly generated will only operate on instance variables declared in the
current Objective-C class, and not those inherited from superclasses. It
is the responsibility of the Objective-C runtime to invoke all such methods
in an object's inheritance hierarchy. The - (id) .cxx_construct
methods
will be invoked by the runtime immediately after a new object
instance is allocated; the - (void) .cxx_destruct
methods will
be invoked immediately before the runtime deallocates an object instance.
As of this writing, only the NeXT runtime on Mac OS X 10.4 and later has
support for invoking the - (id) .cxx_construct
and
- (void) .cxx_destruct
methods.
-fobjc-direct-dispatch
-fobjc-exceptions
@try { ... @throw expr; ... } @catch (AnObjCClass *exc) { ... @throw expr; ... @throw; ... } @catch (AnotherClass *exc) { ... } @catch (id allOthers) { ... } @finally { ... @throw expr; ... }
The @throw
statement may appear anywhere in an Objective-C or
Objective-C++ program; when used inside of a @catch
block, the
@throw
may appear without an argument (as shown above), in which case
the object caught by the @catch
will be rethrown.
Note that only (pointers to) Objective-C objects may be thrown and
caught using this scheme. When an object is thrown, it will be caught
by the nearest @catch
clause capable of handling objects of that type,
analogously to how catch
blocks work in C++ and Java. A
@catch(id ...)
clause (as shown above) may also be provided to catch
any and all Objective-C exceptions not caught by previous @catch
clauses (if any).
The @finally
clause, if present, will be executed upon exit from the
immediately preceding @try ... @catch
section. This will happen
regardless of whether any exceptions are thrown, caught or rethrown
inside the @try ... @catch
section, analogously to the behavior
of the finally
clause in Java.
There are several caveats to using the new exception mechanism:
NS_HANDLER
-style
idioms provided by the NSException
class, the new
exceptions can only be used on Mac OS X 10.3 (Panther) and later
systems, due to additional functionality needed in the (NeXT) Objective-C
runtime.
@throw
an exception
from Objective-C and catch
it in C++, or vice versa
(i.e., throw ... @catch
).
The -fobjc-exceptions switch also enables the use of synchronization blocks for thread-safe execution:
@synchronized (ObjCClass *guard) { ... }
Upon entering the @synchronized
block, a thread of execution shall
first check whether a lock has been placed on the corresponding guard
object by another thread. If it has, the current thread shall wait until
the other thread relinquishes its lock. Once guard
becomes available,
the current thread will place its own lock on it, execute the code contained in
the @synchronized
block, and finally relinquish the lock (thereby
making guard
available to other threads).
Unlike Java, Objective-C does not allow for entire methods to be marked
@synchronized
. Note that throwing exceptions out of
@synchronized
blocks is allowed, and will cause the guarding object
to be unlocked properly.
-fobjc-gc
-freplace-objc-classes
-fzero-link
objc_getClass("...")
(when the name of the class is known at
compile time) with static class references that get initialized at load time,
which improves run-time performance. Specifying the -fzero-link flag
suppresses this behavior and causes calls to objc_getClass("...")
to be retained. This is useful in Zero-Link debugging mode, since it allows
for individual class implementations to be modified during program execution.
-gen-decls
-Wassign-intercept
(Objective-C and Objective-C++ only)-Wno-protocol
(Objective-C and Objective-C++ only)-Wselector
(Objective-C and Objective-C++ only)@selector(...)
expression, and a corresponding method for that selector has been found
during compilation. Because these checks scan the method table only at
the end of compilation, these warnings are not produced if the final
stage of compilation is not reached, for example because an error is
found during compilation, or because the -fsyntax-only option is
being used.
-Wstrict-selector-match
(Objective-C and Objective-C++ only)id
or Class
. When this flag
is off (which is the default behavior), the compiler will omit such warnings
if any differences found are confined to types which share the same size
and alignment.
-Wundeclared-selector
(Objective-C and Objective-C++ only)@selector(...)
expression referring to an
undeclared selector is found. A selector is considered undeclared if no
method with that name has been declared before the
@selector(...)
expression, either explicitly in an
@interface
or @protocol
declaration, or implicitly in
an @implementation
section. This option always performs its
checks as soon as a @selector(...)
expression is found,
while -Wselector only performs its checks in the final stage of
compilation. This also enforces the coding style convention
that methods and selectors must be declared before being used.
-print-objc-runtime-info