property_getAttributes()는 읽기 전용으로 설정된 경우 retain, strong, weak 및 assign 속성간에 차이를 만들지 않습니다.

Question

property_getAttributes() 런타임 기능을 사용하여 객체의 속성 속성을 가져 오려고합니다. 일부 속성은 읽기 전용으로 설정됩니다. 그러나 문제는 retain/strong, weak 및 assign 속성 간의 차이를 만들려고 할 때입니다. 예 :

의 우리가 있다고 가정 해 봅시다 :

@interface MyObject : NSObject 
@property (assign, readonly) NSObject *prop1; 
@property (strong, readonly) NSObject *prop2; 
@property (weak, readonly) NSObject *prop3; 
@end 

우리는 속성 목록 및 인쇄를 얻을 수

int outCount; 
objc_property_t *properties = class_copyPropertyList([MyObject class], &outCount); 
for(i = 0; i < outCount; i++) { 
    objc_property_t property = properties[i]; 
    const char *c_attributes = property_getAttributes(property); 
    printf("%s", c_attributes); 
} 
free(properties); 

결과가 없습니다 :

T@"NSObject",R,V_prop1 
T@"NSObject",R,V_prop2 
T@"NSObject",R,V_prop3 

... 그래서 특정 코드 weak, strong/retain, 읽기 전용 일 때 속성 할당 :(

질문은입니다 : 속성이 약하고 강하다는 것을 아는 다른 방법이 있습니까?

Answer 1

내가 코드를 시도했지만

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/objcruntimeguide/articles/ocrtpropertyintrospection.html

R 속성은 읽기 전용에 따라하지 않은이 (읽기 전용)

C는 속성이 할당 된 마지막 값의 사본 (부).

&이 속성은 마지막으로 할당 된 값 (retain)에 대한 참조입니다.

N 속성은 비 원자 (비 원자)입니다.

G이 속성은 사용자 지정 getter 선택기 이름을 정의합니다. 이름은 G 뒤에옵니다 (예 : GcustomGetter).

S이 속성은 사용자 지정 선택기 선택기 이름을 정의합니다. 이름은 S 다음에옵니다 (예 : ScustomSetter :,).

D 속성이 동적입니다 (@ 동적).

W 속성은 약한 참조 (__weak)입니다.

P이 속성은 가비지 수집 대상입니다.

t 이전 스타일 인코딩을 사용하여 유형을 지정합니다.

Answer 2

질문에 신속하게 답변하려면 답변이 아니오입니다.

여기서의 문제는 그 속성에 대한 메모리 관리 의미론 (들이다 assign, unsafe_unretained, strong, weak, copy ARC와 assign, retain, MRC에 copy)에 만 자동으로 생성 세터 코드의 모든 애플리케이션이있다. 속성에 대한 자신 만의 세터를 작성해야한다면 당연히 시맨틱을 직접 구현하는 것이 좋습니다 (필수는 아님). 이러한 속성의 getter는 이러한 속성 속성에 의해 전혀 수정되지 않습니다.호출자가 강하거나 약한 참조와 반환 값이 하나가 적어도 한 호출 코드가 문을 완료하는 데 필요한대로 위해 살아야 할 것입니다 이러한 상황에서

@interface FooBar() 
@property (nonatomic, strong, readonly) NSString* foobar; 
@end 

@implementation FooBar 
- (NSString*) foobar { 
    return [NSString stringWithFormat:@"aString"]; 
} 

:이 코드를 생각해 보자. 약한 참조의 경우 strong의 속성이 참조 된 객체가 사용자를 위해 보관된다는 것을 보장하지 않기 때문에 나중에 nil으로 갈 것입니다. 궁극적으로 readonly 속성의 메모리 관리는 대부분 버릇이나 스타일로 끝나는 위약에 불과합니다. @property (nonatomic, readonly) ...은 완벽하게 합법적이지만 속성 선언에서 메모리 특성과 마주 칠 때 혼란 스럽습니다.

추 신 : property_copyAttributeList이라는 런타임에 또 다른 기능이 있는데이 정보를 구문 분석하기가 훨씬 쉽습니다 (구조체를 사용하여 구성 요소를 분해합니다).