製作小型開源iOS API時，如何考慮ARC和非弧形用戶

我曾見過一些庫在其源代碼管理中使用獨立的分支。一個用於非ARC的ARC。我不認爲這是局部的，因爲它需要額外的維護。製作小型開源iOS API時，如何考慮ARC和非弧形用戶

我想到一個方法是使用下面的編譯選項：（見this問題）

#if __has_feature(objc_arc)

每當我需要使用retain釋放等..這樣，如果用戶已經是打開的代碼將自動重新考慮自身因素。

這樣做有缺點嗎？
有沒有更好的方法來做到這一點？

來源

2012-01-08 Robert

雖然戴夫的答案是正確的，但有一種替代模式可以避免必須在代碼中維護兩種內存模型。

也就是說，編譯代碼與ARC要求，並且：

使用靜態庫distrubute你的代碼;無論該靜態庫是由目標項目中的新目標構建還是分發庫本身，都可以爲構建庫的目標打開ARC。
僅在文件添加到目標項目中的任何目標時打開ARC。 ARC可以打開每個文件。

在任何情況下，在每個文件級混合ARC和非ARC代碼是完全支持和工作得很好（的事實所證明，該系統架構幾乎完全編譯非ARC，但從ARC工作得很好）。

來源

2012-01-08 15:40:18 bbum

偉大的答案，我相信每個文件的解決方案將優於使用宏。 – Robert 2012-01-08 22:35:23

這幾乎是我如何做到這一點。 I also have some macros讓我的代碼保持相對「乾淨」：

#if __has_feature(objc_arc) 

#define DD_HAS_ARC 1 
#define DD_RETAIN(_o) (_o) 
#define DD_RELEASE(_o) 
#define DD_AUTORELEASE(_o) (_o) 

#else 

#define DD_HAS_ARC 0 
#define DD_RETAIN(_o) [(_o) retain] 
#define DD_RELEASE(_o) [(_o) release] 
#define DD_AUTORELEASE(_o) [(_o) autorelease] 

#endif

有了這些，我可以做的東西，如：

return DD_AUTORELEASE(DD_RETAIN(_myIvar));

或者：

DD_RELEASE(_myIvar); 
_myIvar = DD_RETAIN(newObject);

或者：

- (void)dealloc { 
    DD_RELEASE(_myIvar); 

    #if !DD_HAS_ARC 
    [super dealloc]; 
    #endif 
}

然後宏展開根據我是否使用ARC進行編譯，找到正確的代碼。

來源

2012-01-08 15:11:33

如果你正在開發一個靜態（編譯）庫，那麼你可以使用任何你想要的方法。
大部分的差異是在編譯時。
這意味着生成的輸出應該是相同的（如果您在非ARC版本中正確管理內存）。
編譯完成後，任何項目都可以使用它，而不必關心您的庫是使用或不使用ARC開發的。底線，您可以開發一個基於ARC的庫，並將其用於非ARC項目（反之亦然），而不會出現問題。

來源

2012-01-08 15:36:56

製作小型開源iOS API時，如何考慮ARC和非弧形用戶

回答

相關問題