óÀ½, ÀÌÀü, ´ÙÀ½, ¸¶Áö¸· Àý·Î°¡±â, ¸ñÂ÷.
The GNU Objective-C runtime provides a way that allows you to execute
code before the execution of the program enters the
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
Suppose for example you have a ¿ø¹®½ÃÀÛ
+load
: Executing code before mainmain
function. The code is executed on a per-class and a per-category basis,
through a special class method +load
.
+initialize
method, might not be useful because
+initialize
is only called when the first message is sent to a
class object, which in some cases could be too late.
FileStream
class that declares
Stdin
, Stdout
and Stderr
as global variables, like
below:
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
¿ø¹®³¡
+load
: main ÀüÀÇ ½ÇÇàÄÚµå
GNU Objective-C runtimeÀº ÇÁ·Î±×·¥ ½ÇÇàÀÌ main
ÇÔ¼ö·Î µé¾î°¡±âÀü¿¡ Äڵ带 ½ÇÇàÇÒ ¼ö ÀÖµµ·Ï Çã¿ëÇÏ´Â ¹æ¹ýÀ» Á¦°øÇÑ´Ù. ÄÚµå´Â per-class¿Í per-category ±â¹Ý¿¡¼ Ưº°ÇÑ Å¬·¡½º ¸Þ½áµå(method)ÀÎ +load
¸¦ ÅëÇØ ½ÇÇàµÈ´Ù.
ÀÌ·¯ÇÑ ±â´ÉÀº ¸ÕÀú Ŭ·¡½º¿¡ ¸Þ½ÃÁö¸¦ º¸³»Áö ¾Ê°í, ÇÁ·Î±×·¥¿¡ ÀÇÇØ Á÷Á¢ Á¢±ÙµÉ ¼ö ÀÖ´Â Àü¿ªº¯¼ö¸¦ ÃʱâÈÇÏ°í ½ÍÀº °æ¿ì¿¡ ¸Å¿ì À¯¿ëÇÏ´Ù. +initialize
¸Þ½áµå¿¡¼ Àü¿ªº¯¼ö¸¦ ÃʱâȽÃÅ°´Â ÀϹÝÀûÀÎ ¹æ¹ýÀº À¯¿ëÇÏÁö ¾Ê´Ù. ¿Ö³ÄÇϸé +initialize
´Â ÃÖÃÊ ¸Þ½ÃÁö°¡ ¾î¶² Ŭ·¡½º °´Ã¼¿¡ Àü´ÞµÉ ¶§¸¸ ºÒ·ÁÁö±â¶§¹®ÀÌ´Ù.
¿¹¸¦ µé¾î, ¾Æ·¡¿Í °°ÀÌ Stdin
, Stdout
, Stderr
¸¦ Àü¿ªº¯¼ö·Î ¼±¾ðÇÑ FileStream
Ŭ·¡½º¸¦ °¡Áö°í ÀÖ´Ù°í °¡Á¤ÇÏÀÚ:
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
In this example, the initialization of Stdin
, Stdout
and
Stderr
in +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 nil
object. The
+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 main
.
The correct solution of the above problem is to use the +load
method instead of +initialize
:
@implementation FileStream + (void)load { Stdin = [[FileStream new] initWithFd:0]; Stdout = [[FileStream new] initWithFd:1]; Stderr = [[FileStream new] initWithFd:2]; } /* Other methods here */ @end
The +load
is a method that is not overridden by categories. If a
class and a category of it both implement +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 +initialize
.
You should be aware of its limitations when you decide to use it
instead of +initialize
.
ÀÌ ¿¹¿¡¼ +initialize³»ÀÇ Stdin
, Stdout
, Stderr
ÀÇ ÃʱâÈ´Â ³Ê¹« ´Ê°Ô ÀϾÙ.
ÇÁ·Î±×·¡¸Ó´Â º¯¼öµéÀÌ ½ÇÁ¦·Î ÃʱâȵDZâÀü¿¡ ÀÌ·¯ÇÑ °´Ã¼µé ÁßÀÇ Çϳª¿¡°Ô ÇϳªÀÇ ¸Þ½ÃÁö¸¦ º¸³¾ ¼ö ÀÖ´Ù. ÀÌ·¸°Ô nil
°´Ã¼¿¡ ¸Þ½ÃÁö¸¦ º¸³½´Ù. Àü¿ªº¯¼ö¸¦ ½ÇÁ¦·Î ÃʱâÈÇÏ´Â +initialize
¸Þ½áµå´Â ÃÖÃÊ ¸Þ½ÃÁö°¡ Ŭ·¡½º °´Ã¼¿¡ º¸³»Áú ¶§±îÁö È£ÃâµÇÁö ¾Ê´Â´Ù. À̸¦ ÇØ°áÇÏ·Á¸é main
¿¡ µé¾î°¡±â ¹Ù·ÎÀü¿¡ ÀÌµé º¯¼ö°¡ ÃʱâȵǾî¾ß ÇÑ´Ù.
À§ ¹®Á¦ÀÇ Á¤´äÀº +initialize
´ë½Å¿¡ +load
¸Þ½áµå¸¦ »ç¿ëÇÏ´Â °ÍÀÌ´Ù:
@implementation FileStream + (void)load { Stdin = [[FileStream new] initWithFd:0]; Stdout = [[FileStream new] initWithFd:1]; Stderr = [[FileStream new] initWithFd:2]; } /* Other methods here */ @end
+load
´Â Ä«Å×°í¸®(category)¿¡ ÀÇÇØ ¿À¹ö¶óÀ̵ù(overriding)µÉ ¼ö ¾ø´Â ¸Þ½áµåÀÌ´Ù. ¸¸¾à Ŭ·¡½º¿Í Ä«Å×°í¸®°¡ ¸ðµÎ +load
¸¦ ½ÇÇàÇÏ°í ÀÖ´Ù¸é, µÎ°³ÀÇ ¸Þ½áµå°¡ È£ÃâµÈ´Ù. ÀÌ°ÍÀº ¸î°¡Áö ºÎ°¡ÀûÀÎ ÃʱâÈ°¡ Ä«Å×°í¸®¿¡¼ ¼öÇàµÉ ¼ö ÀÖµµ·Ï ÇØÁØ´Ù. ÀÌ·¯ÇÑ ¸ÞÄ«´ÏÁòÀº +initialize
¸¦ ´ëüÇÒ·Á´Â Àǵµ´Â ¾Æ´Ï´Ù. ¿©·¯ºÐÀº +initialize
¸¦ ´ë½ÅÇØ ÀÌ ¸Þ½îµå¸¦ »ç¿ëÇϱâ·Î °áÁ¤ÇÒ ¶§ ÀÌ ¸Þ½îµåÀÇ Á¦ÇÑ »çÇ×µéÀ» ¾Ë¾Æ¾ß ÇÑ´Ù.
+load
The +load
implementation in the GNU runtime guarantees you the following
things:
+load
implementation of all super classes of a class are executed before the +load
of that class is executed;
+load
implementation of a class is executed before the
+load
implementation of any category.
In particular, the following things, even if they can work in a particular case, are not guaranteed:
You should make no assumptions about receiving +load
in sibling
classes when you write +load
of a class. The order in which
sibling classes receive +load
is not guaranteed.
The order in which +load
and +initialize
are called could
be problematic if this matters. If you don't allocate objects inside
+load
, it is guaranteed that +load
is called before
+initialize
. If you create an object inside +load
the
+initialize
method of object's class is invoked even if
+load
was not invoked. Note if you explicitly call +load
on a class, +initialize
will be called first. To avoid possible
problems try to implement only one of these methods.
The +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 +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.
+load
¿¡¼ °¡´ÉÇÑ °Í°ú ºÒ°¡´ÉÇÑ °Í
GNU runtime¿¡¼ +load
ÀÇ ½ÇÇàÀº ´ÙÀ½°ú °°Àº °ÍµéÀ» º¸ÀåÇÑ´Ù:
+load
ÀÇ ½ÇÇàÀº ±× Ŭ·¡½ºÀÇ +load
°¡ ½ÇÇàµÇ±â Àü¿¡ ½ÇÇàµÈ´Ù;
+load
ÀÇ ½ÇÇàÀº ¾î¶°ÇÑ Ä«Å×°í¸®ÀÇ +load
½ÇÇຸ´Ùµµ Àü¿¡ ½ÇÇàµÈ´Ù.
ƯÈ÷, ´ÙÀ½ÀÇ °ÍµéÀº Ưº°ÇÑ °æ¿ì¿¡ µ¿ÀÛÇÒÁö´Â ¸ô¶óµµ º¸ÀåµÇÁö´Â ¾Ê´Â´Ù.
ÇÑ Å¬·¡½ºÀÇ +load
¸¦ ¾µ¶§ ÇüÁ¦ Ŭ·¡½º¾ÈÀÇ +load
¸¦ ¹Þ´Â °Í¿¡ ´ëÇØ °¡Á¤Çؼ´Â ¾ÈµÈ´Ù. ÇüÁ¦ Ŭ·¡½º°¡ +load
¸¦ ¹Þ´Â ¼ø¼´Â º¸ÀåÇÏÁö ¾Ê´Â´Ù. ¸¸¾à +load¿Í
+initialize
°¡ ºÒ·ÁÁö´Â ¼ø¼°¡ Áß¿äÇÏ´Ù¸é ¹®Á¦°¡ µÉ ¼ö ÀÖ´Ù. +load
³»ºÎ¿¡ °´Ã¼¸¦ ÇÒ´çÇÏÁö ¾Ê´Â´Ù¸é, +load
°¡ +initialize
Àü¿¡ ºÒ·ÁÁö´Â °ÍÀÌ º¸ÀåµÈ´Ù. ¸¸¾à +load
³»ºÎ¿¡ ÇϳªÀÇ °´Ã¼¸¦ »ý¼ºÇÑ´Ù¸é, °´Ã¼ÀÇ Å¬·¡½º°¡ °¡Áø +initialize
¸Þ½áµå´Â +load
°¡ È£ÃâµÇÁö ¾Ê¾ÒÀ»Áö¶óµµ È£ÃâÇÒ ¼ö ÀÖ´Ù. ¸¸¾à ¾î¶² Ŭ·¡½º¿¡°Ô +load
¸¦ ¸í½ÃÀûÀ¸·Î È£ÃâÇÑ´Ù¸é, +initialize
°¡ ¿ì¼± È£ÃâµÈ´Ù. ¹ß»ý°¡´ÉÇÑ ¹®Á¦Á¡µéÀ» ÇÇÇϱâ À§ÇØ, ÀÌ·¯ÇÑ ¸Þ½áµåµé Áß ¿ÀÁ÷ Çϳª¸¸À» ¼öÇàÇضó.
+load
¸Þ½áµå´Â ¶ÇÇÑ ¹øµé(bundle)ÀÌ ½ÇÇàµÇ°í ÀÖ´Â ÇÁ·Î±×·¥¾È¿¡¼ µ¿ÀûÀ¸·Î ·ÎµåµÉ ¶§ ¹ß»ýÇÒ ¼ö ÀÖ´Ù. ÀÌ°ÍÀº ¾î¶°ÇÑ µ¿ÀÛÀÇ °£¼·¾øÀÌ ÀÚµ¿ÀûÀ¸·Î ¹ß»ýÇÑ´Ù. ¹øµéÀ» ¾µ ¶§¿Í +load
¸¦ ¾²´Â °ÍÀÌ ÇÊ¿äÇÒ ¶§, ¿©·¯ºÐÀº ½ÇÇàÇÁ·Î±×·¥¿¡ ÀÌ¹Ì Á¸ÀçÇϴ Ŭ·¡½ºµéÀÇ °´Ã¼¿¡ ¾ÈÀüÇÏ°Ô ¸Þ½ÃÁö¸¦ ¸¸µé¾î º¸³¾ ¼ö ÀÖ´Ù. À§¿Í °°Àº Á¦ÇÑÀÌ ¹øµé³»¿¡ Á¤ÀÇµÈ Å¬·¡½ºµé¿¡°Ô Àû¿ëµÈ´Ù.
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
|
C
|
s
|
S
|
i
|
I
|
l
|
L
|
q
|
Q
|
f
|
d
|
v
|
@
|
#
|
:
|
*
|
?
|
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)
|
'^' followed by the pointed type.
|
'[' followed by the number of elements in the array followed by the type of the elements followed by ']'
|
'{' followed by the name of the structure (or '?' if the structure is unnamed), the '=' sign, the type of the members and by '}'
|
'(' followed by the name of the structure (or '?' if the union is unnamed), the '=' sign, the type of the members followed by ')'
|
Compiler encoding
|
[10i]
|
{?=i[3f]b128i3b131i2c}
|
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:
Encoding
|
r
|
n
|
N
|
o
|
O
|
V
|
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.
Objective-C ÄÄÆÄÀÏ·¯´Â ¸ðµç Çü¿¡ ´ëÇÑ Å¸ÀÔ ÀÎÄÚµùÀ» ¸¸µç´Ù. ÀÌ·¯ÇÑ Å¸ÀÔ ÀÎÄÚµùÀº ¼¿·ºÅÍ(selector)¿Í ¸Þ½áµå, °´Ã¼, Ŭ·¡½º¿¡ ´ëÇÑ Á¤º¸¸¦ ã±âÀ§ÇØ ½ÇÇà½Ã°£¿¡ »ç¿ëµÈ´Ù.
ÇüÀº ¾Æ·¡ÀÇ ¹æ¹ýÀ¸·Î ÀÎÄÚµùµÈ´Ù.
c
|
C
|
s
|
S
|
i
|
I
|
l
|
L
|
q
|
Q
|
f
|
d
|
v
|
@
|
#
|
:
|
*
|
?
|
b ´ÙÀ½¿¡ ºñÆ®ÇʵåÀÇ ½ÃÀÛÀ§Ä¡, ºñÆ®ÇʵåÀÇ Çü°ú Å©±â(ºñÆ®Çʵå ÀÎÄÚµùÀº NeXTÀÇ ÄÄÆÄÀÏ·¯ ÀÎÄÚµùÀ¸·ÎºÎÅÍ º¯ÈµÇ¾ú´Ù. ¾Æ·¡¸¦ ÂüÁ¶Çضó.)
|
'^' ´ÙÀ½¿¡ Æ÷ÀÎÅÍÇü(pointed type).
|
'[' ´ÙÀ½¿¡ ¹è¿³» ¿ä¼ÒÀÇ ¼ö ´ÙÀ½¿¡ ']'
|
'{' ´ÙÀ½¿¡ ±¸Á¶Ã¼¸í(¶Ç´Â ¸¸¾à ±¸Á¶Ã¼°¡ À̸§ÀÌ ¾ø´Ù¸é '?'), '='±âÈ£, ¸â¹ö(member)ÀÇ Çü ´ÙÀ½¿¡ '}'
|
'(' ´ÙÀ½¿¡ °ø¿ëü¸í(¶Ç´Â ¸¸¾à °ø¿ëü°¡ À̸§ÀÌ ¾ø´Ù¸é '?'), '='±âÈ£, ¸â¹ö(member)ÀÇ Çü ´ÙÀ½¿¡ ')'
|
ÄÄÆÄÀÏ·¯ ÀÎÄÚµù
|
[10i]
|
{?=i[3f]b128i3b131i2c}
|
Çü¿¡ µ¡ºÙ¿© ÄÄÆÄÀÏ·¯´Â ÇüÁöÁ¤ÀÚ(type specifier)µµ ÀÎÄÚµùÇÑ´Ù. ¾Æ·¡ÀÇ Å×À̺íÀº ÇöÀç Objective-C ÇüÁöÁ¤ÀÚÀÇ ÀÎÄÚµùÀ» ±â¼úÇÑ´Ù:
Encoding
|
r
|
n
|
N
|
o
|
O
|
V
|
ÇüÁöÁ¤ÀÚ´Â Çü ¹Ù·Î¾Õ¿¡¼ ÄÚµåȵȴÙ. ±×·¯³ª Çü°ú ´Þ¸® ÇüÁöÁ¤ÀÚ´Â ±×°ÍµéÀÌ ¸Þ½áµå ÀÎÀÚÇü¿¡ ³ªÅ¸³¯ ¶§¸¸ ÄÚµåȵȴÙ.
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
http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
To enable the support for it you have to configure the compiler using an
additional argument, --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,
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
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:
Weak pointers are supported through a new type character specifier
represented by the ¿ø¹®½ÃÀÛ
Garbage Collection
class_ivar_set_gcinvisible()
which can be used to declare a so-called 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 id
,
Class
and SEL
.
@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
'!'
character. The
class_ivar_set_gcinvisible()
function adds or removes this
specifier to the string type description of the instance variable named
as argument.
¿ø¹®³¡
»õ·Î¿î ¸Þ¸ð¸® °ü¸®Á¤Ã¥¿¡ ´ëÇÑ Áö¿øÀº Boehm-Demers-Weiser conservative °¡ºñÁö ¼öÁý±â·Î ¾Ë·ÁÁø °·ÂÇÑ conservative °¡ºñÁö ¼öÁý±â¸¦ ÀÌ¿ëÇÏ¿© Ãß°¡µÇ¾îÁ® ¿Ô´Ù. ÀÌ°ÍÀº http://www.hpl.hp.com/personal/Hans_Boehm/gc/ ¿¡¼ ¾òÀ» ¼ö ÀÖ´Ù.
GC¿¡ ´ëÇÑ Áö¿øÀ» °¡´ÉÄÉÇϱâ À§Çؼ Ãß°¡ÀûÀÎ ÀÎÀÚÀÎ --enable-objc-gc¸¦ ÀÌ¿ëÇÏ¿© ÄÄÆÄÀÏ·¯¸¦ ¼³Á¤ÇØ¾ß ÇÑ´Ù. ÄÄÆÄÀÏ·¯¸¦ ±¸ÃàÇϱâÀü¿¡ °¡ºñÁö ¼öÁý±â°¡ ¼³Ä¡µÇ¾î ÀÖ¾î¾ß ÇÑ´Ù. ÀÌ°ÍÀº °¡ºñÁö ¼öÁý±â¸¦ º¸ÃæÇÑ ¸î°¡Áö °³¼±»çÇ×À» °¡Áø Ãß°¡ÀûÀÎ ·±Å¸ÀÓ ¶óÀ̺귯¸®(runtime library)¸¦ ±¸ÃàÇÒ °ÍÀÌ´Ù. »õ·Î¿î ¶óÀ̺귯¸®´Â °¡ºñÁö ¼öÁýÀ» ÇÏÁö ¾Ê´Â ¶óÀ̺귯¸®(non-garbage-collected library)¿Í Ãæµ¹³ªÁö ¾Ê°Ô libobjc_gc.a¶ó´Â »õ·Î¿î À̸§À» °¡Áø´Ù.
°¡ºñÁö ¼öÁý±â°¡ »ç¿ëµÉ ¶§, °´Ã¼´Â Boehm-Demers-Weiser ¼öÁý±â¿¡¼ À¯È¿ÇÑ ¼ÒÀ§ ÇüÁöÁ¤ ¸Þ¸ð¸® ÇÒ´ç ¸ÞÄ«´ÏÁòÀ» »ç¿ëÇؼ ÇÒ´çµÈ´Ù. ÀÌ ¸ðµå´Â Æ÷ÀÎÅÍ°¡ °´Ã¼ ¾ÈÂÊ ¾îµð¿¡ À§Ä¡Çϴ°¡¿¡ ´ëÇÑ Á¤È®ÇÑ Á¤º¸¸¦ ÇÊ¿ä·Î ÇÑ´Ù. ÀÌ Á¤º¸´Â Ŭ·¡½º°¡ ÃʱâÈµÈ ÈÄ Áï½Ã Ŭ·¡½º¸¶´Ù Çѹø °è»êµÈ´Ù.
¼ÒÀ§ weak Æ÷ÀÎÅÍ ÂüÁ¶(reference)¸¦ ¼±¾ðÇϱâÀ§ÇØ »ç¿ëµÉ ¼ö ÀÖ´Â »õ·Î¿î ·±Å¸ÀÓ ÇÔ¼öÀÎ class_ivar_set_gcinvisible()
°¡ ÀÖ´Ù. ±×·± Æ÷ÀÎÅÍ´Â ±âº»ÀûÀ¸·Î °¡ºñÁö ¼öÁý±â¸¦ À§ÇØ ¼û°ÜÁø´Ù. ÀÌ°ÍÀº ƯÈ÷ ÇÒ´çµÈ °´Ã¼ÀÇ Æ®·¢(track)À» À¯ÁöÇÏ°í ½ÍÀ» ¶§¿Í ¾ÆÁ÷ ±×°ÍµéÀÌ ¼öÁýµÇ´Â °ÍÀ» Çã¶ôÇÏÁö ¾ÊÀ» ¶§¿Í °°Àº ƯÁ¤ »óȲ¿¡¼ À¯¿ëÇÏ´Ù. ÀÌ·± Á¾·ùÀÇ Æ÷ÀÎÅ͵鸸ÀÌ ¿ÀÁ÷ °´Ã¼ÀÇ ¸â¹ö°¡ µÉ ¼ö ÀÖ´Ù. weak ÂüÁ¶·Î Àü¿ª Æ÷ÀÎÅ͸¦ ¼±¾ðÇÒ ¼ö ¾ø´Ù. ¸ðµç Æ÷ÀÎÅÍÇüÀº id
, Class
, SEL
À» °¡Áø weak Æ÷ÀÎÅÍ·Î ¼±¾ðµÉ ¼ö ÀÖ´Ù.
¾Æ·¡´Â ÀÌ·¯ÇÑ ±â´ÉÀ» »ç¿ëÇÏ´Â ¹æ¹ý¿¡ ´ëÇÑ ¿¹Á¦ÀÌ´Ù. ¸¸¾à ÇÑ Å¬·¡½º¸¦ ¼öÇàÇϱ⸦ ¿øÇÑ´Ù¸é ÀÌ ¶§ Ŭ·¡½ºÀÇ ÀνºÅϽº(instance)´Â weak Æ÷ÀÎÅÍ ÂüÁ¶¸¦ °¡Áø´Ù. ´ÙÀ½ÀÇ Å¬·¡½º°¡ ÀÌ·¸°Ô ÀÛµ¿µÈ´Ù:
@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
weak Æ÷ÀÎÅÍ´Â '!'
¹®ÀÚ·Î ³ªÅ¸³½ »õ·Î¿î Çü¹®ÀÚ ÁöÁ¤ÀÚ¸¦ ÅëÇØ Áö¿øµÈ´Ù. class_ivar_set_gcinvisible()
ÇÔ¼ö´Â ÀÎÀÚ·Î ¸í¸íµÈ ÀνºÅϽº º¯¼öÀÇ ¹®ÀÚ¿ Çü ±â¼ú¸ñ·Ï(description)¿¡ ÀÌ ÁöÁ¤ÀÚ¸¦ Ãß°¡Çϰųª Á¦°ÅÇÑ´Ù.
GNU Objective-C provides constant string objects that are generated
directly by the compiler. You declare a constant string object by
prefixing a C constant string with the character @
:
id myString = @"this is a constant string object";
The constant string objects are usually instances of the
NXConstantString
class which is provided by the GNU Objective-C
runtime. To get the definition of this class you must include the
`objc/NXConstStr.h' header file.
User defined libraries may want to implement their own constant string
class. To be able to support them, the GNU Objective-C compiler provides
a new command line options -fconstant-string-class=<class
name>
. The provided class should adhere to a strict structure, the same
as NXConstantString
's structure:
@interface NXConstantString : Object { char *c_string; unsigned int len; } @end
User class libraries may choose to inherit the customized constant
string class from a different class than Object
. There is no
requirement in the methods the constant string class has to implement.
When a file is compiled with the -fconstant-string-class
option,
all the constant string objects will be instances of the class specified
as argument to this option. It is possible to have multiple compilation
units referring to different constant string classes, neither the
compiler nor the linker impose any restrictions in doing this.
GNU Objective-C´Â ÄÄÆÄÀÏ·¯¿¡ ÀÇÇØ Á÷Á¢ »ý¼ºµÈ »ó¼ö ¹®ÀÚ¿(constant string) °´Ã¼¸¦ Á¦°øÇÑ´Ù. C »ó¼ö ¹®ÀÚ¿ ¾Õ¿¡ ¹®ÀÚ @
¸¦ ºÙÀÓÀ¸·Î½á »ó¼ö ¹®ÀÚ¿ °´Ã¼¸¦ ¼±¾ðÇÑ´Ù:
id myString = @"this is a constant string object";
»ó¼ö ¹®ÀÚ¿ °´Ã¼´Â ÀϹÝÀûÀ¸·Î GNU Objective-C runtime¿¡ ÀÇÇØ Á¦°øµÈ NXConstantString
Ŭ·¡½ºÀÇ ÀνºÅϽºÀÌ´Ù. ÀÌ Å¬·¡½ºÀÇ Á¤ÀǸ¦ ¾òÀ¸·Á¸é, `objc/NXConstStr.h' Çì´õ ÆÄÀÏ(header file)À» Æ÷ÇÔ ½ÃÄÑ¾ß ÇÑ´Ù.
»ç¿ëÀÚ Á¤ÀÇ ¶óÀ̺귯¸®´Â ±×µé ÀÚ½ÅÀÇ »ó¼ö ¹®ÀÚ¿ Ŭ·¡½º¸¦ ¼öÇàÇÏ°íÀÚ ÇÒÁöµµ ¸ð¸¥´Ù. ±×°ÍµéÀ» Áö¿øÇÒ ¼ö ÀÖµµ·Ï GNU Objective-C ÄÄÆÄÀÏ·¯´Â »õ·Î¿î ¸í·ÉÇà ¿É¼Ç(command line option)À¸·Î -fconstant-string-class=<class
name>
À» Á¦°øÇÑ´Ù. Á¦°øµÈ Ŭ·¡½º´Â NXConstantString
ÀÇ ±¸Á¶¿Í °°Àº ¾ö°ÝÇÑ(strict) ±¸Á¶¸¦ ÁöÄÑ¾ß ÇÑ´Ù.
@interface NXConstantString : Object { char *c_string; unsigned int len; } @end
»ç¿ëÀÚ Å¬·¡½º ¶óÀ̺귯¸®´Â °´Ã¼
º¸´Ù´Â ´Ù¸¥ Ŭ·¡½º·ÎºÎÅÍ Ä¿½ºÅ͸¶ÀÌ¡µÈ »ó¼ö ¹®ÀÚ¿ Ŭ·¡½º¸¦ »ó¼Ó ¹Þ´Â °ÍÀ» ÅÃÇÒÁöµµ ¸ð¸¥´Ù. »ó¼ö ¹®ÀÚ¿ Ŭ·¡½º°¡ ¼öÇàÇؾßÇÏ´Â ¸Þ½áµå³»¿¡ ¿ä±¸ »çÇ×Àº ¾ø´Ù.
ÆÄÀÏÀÌ -fconstant-string-class
¿É¼ÇÀ» °¡Áö°í ÄÄÆÄÀÏ µÉ ¶§, ¸ðµç »ó¼ö ¹®ÀÚ¿ °´Ã¼´Â ÀÌ ¿É¼Ç¿¡ ÀÎÀڷνá ÁöÁ¤µÈ Ŭ·¡½ºÀÇ ÀνºÅϽº°¡ µÉ °ÍÀÌ´Ù. ´Ù¸¥ »ó¼ö ¹®ÀÚ¿ Ŭ·¡½º¿¡ µû¶ó ´ÙÁß ÄÄÆÄÀÏ ÀåÄ¡(multiple compilation unit)¸¦ °¡Áú ¼ö ÀÖ°í, ÄÄÆÄÀÏ·¯¿Í ¸µÄ¿(linker)´Â À̸¦ ¼öÇàÇÔ¿¡ ÀÖ¾î¼ ¾î¶°ÇÑ Á¦Çѵµ °áÄÚ °¡ÇÏÁö ¾Ê´Â´Ù.
óÀ½, ÀÌÀü, ´ÙÀ½, ¸¶Áö¸· Àý·Î °¡±â, ¸ñÂ÷.