3

I made a static library that was coded using ARC. I plan to distribute this library for other people to use. I understand that nothing needs to be done to include an ARC static library in a non-ARC project, but what about including ARC header files? For example, the headers for my ARC static library declare properties as weak and strong but when I try to include these headers in a non-ARC project, the compiler freaks out.

Any ideas?

edc1591
  • 10,146
  • 6
  • 40
  • 63
  • If I'm not wrong, this can not be done. You can disable ARC for some files inside an ARC project, but not the opposite... I think that you should consider to migrate you project to ARC. This question may help: http://stackoverflow.com/questions/6368600/some-questions-about-automatic-reference-counting-in-ios5-sdk – bontoJR Mar 06 '12 at 15:47
  • 1
    You can turn on ARC for individual files by passing `-fobjc-arc`. But the question relates to a pre-compiled static library. I assume the entire library will be built with ARC. – Rob Napier Mar 06 '12 at 16:02
  • Yeah, the entire library is built with ARC. – edc1591 Mar 06 '12 at 23:58
  • 1
    @JuniorB. - You can indeed use an ARC-enabled framework within a non-ARC application (I do this right now for one of my open source frameworks). Beyond header compatibility, the only other thing you need to watch out for is that if you deploy to Snow Leopard or iOS 4.x, you will need to add `-fobjc-arc` to your Other Linker Flags for your application in order for the necessary libarclite to be linked in. – Brad Larson Mar 07 '12 at 17:25

1 Answers1

3

For strong, you can just use retain. They're identical.

weak is trickier, and while I know several ways that should work, I'm not certain the best way to handle it.

First, make sure you actually need it. If you're supporting iOS4, you can't have weak anyway, so the issue is moot. My gut feeling is that I'd probably just avoid weak and make all these problems go away. weak is nice, but it's not that big a deal to avoid in most cases.

That said, there are some approaches that will work. The best is probably to declare weak accessors without properties in the header. Instead of this:

@property (nonatomic, readwrite, weak) id delegate;

Do this:

- (id)delegate;
- (void)setDelegate:(id)aDelegate;

Then you can still declare a weak property inside your implementation file. The caller can still use dot notation for this, BTW.

It's possible that you'll get a compile error here, since setDelegate: technically takes a __strong id. If that's the case, just hand-implement setDelegate:

- (void)setDelegate:(id)aDelegate {
  _delegate = aDelegate;
}

Haven't tested it, but that should work. You might also declare the ivar _delegate to be __weak in the @implementation block rather than declaring it as a weak property.

Like I said; I haven't tested any of this out. Please post your findings if it works.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • If it's a static library that's already compiled, then you can simply change the header that's imported into the application, as that header has no effect on the implementation compiled in the static library. – Richard J. Ross III Mar 06 '12 at 18:22
  • Very interesting point. Slightly terrifying, but probably effective. I'm not aware of a pre-processor macro you could use for this, but that would make this approach simpler. – Rob Napier Mar 06 '12 at 18:31
  • That could be a possibility. Are there any arguments against doing this, or would it be pretty safe? – edc1591 Mar 06 '12 at 23:59
  • Modifying signatures for different readers frightens me. I've been seriously burned by it before. But I can't really think of any reason it would blow up in this case. – Rob Napier Mar 07 '12 at 00:56