일부 라이브러리는 소스 컨트롤에서 별도의 분기를 사용하는 것으로 나타났습니다. 하나는 ARC가 아닌 ARC 용입니다. 나는 이것이 여분의 유지력을 필요로하기 때문에 이것을 부분적으로 보지 않는다.작은 오픈 소스 iOS API를 만들 때 아크 및 비 아크 사용자를 어떻게 처리합니까?
내가 생각하는 방법은 컴파일러 플래그를 사용하는 것이 었습니다 : 사용자가 코드에 전환 한 경우 나는 등 retain 버전을 사용해야 할 때마다 ... 그 방법을
#if __has_feature(objc_arc)
을 (this 질문 참조) 것 자동으로 스스로를 다시 요소 화합니다.
이렇게하면 단점이 있습니까?
더 좋은 방법이 있습니까?
Dave의 대답은 정확하지만 코드에 두 개의 메모리 모델을 유지해야하는 번거 로움을 피할 수있는 대체 패턴이 있습니다.
즉, ARC하여 코드를 컴파일이 필요하고 다음 중 하나
이 코드를 distrubute하는 정적 라이브러리를 사용; 해당 정적 라이브러리가 대상 프로젝트의 새 대상에 의해 작성되거나 라이브러리 자체를 배포 할 때 라이브러리를 빌드하는 대상에 대해 ARC를 설정할 수 있습니다.
대상 프로젝트의 대상에 추가 할 때 파일 만 ARC로 설정하십시오. ARC는 파일별로 켤 수 있습니다.당 파일 수준에서 ARC 및 비 ARC 코드를 혼합 어떤 경우
그건 제가하는 일입니다. 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
}
그리고 매크로 expa ARC로 컴파일하는지 여부에 따라 올바른 코드로 nds.
정적 (컴파일 된) 라이브러리를 개발중인 경우 원하는 방식으로 접근 할 수 있습니다.
차이점은 대부분 컴파일 타임에 있습니다.
생성 된 출력이 동일해야 함을 의미합니다 (비 ARC 버전에서 메모리를 올바르게 관리하는 경우).
일단 컴파일하면 ARC 사용 여부에 관계없이 라이브러리를 개발했는지 여부에 관계없이 프로젝트를 사용할 수 있습니다.
결론적으로 ARC 기반 라이브러리를 개발하여 ARC가 아닌 프로젝트 (비자)에서 문제없이 사용할 수 있습니다.
위대한 답변은 파일 단위 솔루션이 매크로를 사용하는 것이 더 좋을 것이라고 생각합니다. – Robert