2009-08-28 64 views
1

這個問題隨之而來的是上一個問題,這引發了進一步的問題。我試圖理解的是,當這個例子中的指針和對象正在被創建並且最終發生在他們身上時。我仍然試圖讓這個問題得到解決,所以請原諒我可能提出的任何錯誤假設。NSString的setter,它是如何工作的?

// MAIN 
int main (int argc, const char * argv[]) { 
    PlanetClass *newPlanet_01 = [[PlanetClass alloc] init]; 
    [newPlanet_01 setGeekName:@"StarWars"]; 
} 

// CLASS 
@interface PlanetClass : NSObject { 
    NSString *geekName; 
} 

- (NSString*) geekName; 
- (void) setGeekName:(NSString*)gName; 
@end 

// SETTER 
- (void)setGeekName:(NSString *)gName { 
    if (geekName != gName) { 
     [geekName release]; 
     geekName = [gName copy]; 
    } 
} 

(A)......當PlanetClass「newPlanet_01」的一個實例,首先創建僅僅是一個指針創建的NSString實例變量對象,或一個可能的未來對象?如果它只是一個指針,那麼在setter中稍後將它釋放爲只是一個指針,而不是指向一個對象的指針?

(B)...在上面的例子中,「gName」是一個指向NSString對象@「StarWars」的指針?

(C)......接下來是指針geekName從不同的gname(即如果geekName確實在@ 「星球大戰」 沒有點)

(d)... geekName發佈,什麼被釋放第一次運行代碼時,我的理解是geekName只是一個指向任何東西的指針。或者釋放只是第一次發佈什麼? (E)...最後geekName = [gName copy];新發布的geekName現在被分配指向gName的副本,原始gName會發生什麼變化?

回答

2
  1. 您正在創建一個初始化爲nil的指針。如果您熟悉C或Java,那麼nilNULLnull基本上是相同的 - 它實際上是指向無。
  2. 是的。 @"StarWars"被稱爲「字符串文字」。將字符串文字看作是由程序存儲的「永久」字符串,並且(在這種情況下)是指向該字符串的存儲器位置的指針。
  3. 是的 - 該行確保傳入的gName與對象的geekName變量不相同。假設檢查不存在,並且gNamegeekName指向相同的字符串 - 則下一行將釋放該字符串,這可能會使下一行行無效(它將複製已釋放的字符串 - 非常糟糕! )。
  4. 假設geekName仍然是nil,那麼是的,沒有任何被釋放;或者說,release消息被髮送到nil對象,該對象不會對消息執行任何操作。 (與Objective-C中的C或Java不同,您可以將消息發送到nil - 但所有此類消息都將被忽略,並且nil是來自所有此類消息的返回值)。
  5. 你萬一gName創建gName副本真的NSMutableString的實例 - 你不希望其他代碼變異,你是治療對象的不可變的字符串。但gName指向的對象原始會發生什麼?那麼,這取決於調用者用它做什麼。它可以被釋放,它可以被保留,它可以被傳遞給另一個對象......你並不知道。在這個特殊情況下,由於gName指向字符串文字「StarWars」,因此該對象沒有任何反應(因爲它是一個字符串文字 - 參見上文)。指針本身只在該方法的範圍內有效,並且一旦該方法返回就消失。
+0

我有一個關於5/E的問題。在這種情況下,是內存泄漏嗎?常量字符串會發生什麼?他們的記憶是如何回收的? – jergason 2009-08-28 15:27:55

+0

非常感謝,完美。關於(5/E),我猜想當它超出範圍時它會自動銷燬(自動),但這只是猜測,因爲我已經這樣做了8天:) – fuzzygoat 2009-08-28 15:33:20

+1

這不是內存泄漏。您不會從字符串常量中回收內存 - 它們會在程序期間停留。對於字符串常量,創建它們的代碼由編譯器發出(因此是可執行二進制文件的一部分) - 具體地說,它們存儲在一個稱爲二進制文件的「數據段」的區域中(程序指令被存儲在「文本段」中)。所以你不必擔心「釋放」或「泄漏」字符串常量的內存。 (這至少適用於C和C派生語言,如ObjC。) – mipadi 2009-08-28 15:33:50

相關問題