Re: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:25, Alex Zavatone  wrote:
> Would it be recommended to package my ARC code with ARC turned off and 
> package that in a framework and then link to that from the non ARC app that 
> will need to load it?

 Nope, that would leak all over the place, or dangle pointers depending on 
whether you're prone to using alloc/init and new to create your objects, or 
factory methods.

 Think of ARC this way: ARC manages memory for you (except for circles of 
strong references, aka retain cycles, those you have to resolve by marking 
back-references as weak) inside ARC-using source files. Basically, it inserts 
the requisite retain/release calls for you. So, once generated, ARC code is 
(for all we care for this discussion) undistinguishable from non-ARC code.

 However, you need to help ARC at the bridging point between ARC and non-ARC by 
following ObjC's naming conventions, and also by properly marking references as 
strong or weak. For your non-ARC classes that are referenced by ARC, this means 
if you have a -copyMachine factory method, ARC will see the "copy" and assume 
it's a method with copy semantics instead (+1 reference returned), and end up 
over-releasing the +0 reference of the factory method. The other way round is 
similar. If you create a -copyMachine method, ARC will just return a +1 
reference from it and any other code using it must release it once done to 
avoid leaking.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Quincey Morris]

On Feb 25, 2016, at 22:15 , Uli Kusterer  wrote:
> 
> Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? 
> Because +new is documented to just be a shorthand for +alloc followed by 
> -init on the result, so +newBlah behaving differently than +new sounds kinda 
> inconsistent to me. Did I miss a serious gotcha there?

No, you’re correct. I was making a valid point using the wrong example.

As you said, if the name of a class method begins with “new”, it belongs to the 
“new” family, and it’s implicitly marked with 
'__attribute__((ns_returns_retained))’. That means it has +1 semantics.

What I was actually thinking of was factory methods that *don’t* begin with 
“new”, such as -[NSArray array]. These typically have +0 semantics. My point 
(which I think I’ve now demonstrated pretty vividly) is that if you don’t 
remember what the conventions are, it’s easy to go wrong in MMR.

Interestingly, in the old days, people argued about whether to do [[NSArray 
alloc] init] or [NSArray array], based on clarity vs. efficiency (avoidance of 
an autorelease). As soon as ARC took charge, no one cared any more, because ARC 
offered at least the possibility of both forms being efficient at run time. Now 
that we have conversions into Swift, using compatible naming of factory methods 
is important again. Plus ça change, …

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:47, Quincey Morris  
wrote:
> For example, an object obtained via [[…alloc]init…] is generally assumed to 
> be returned with a +1 ownership, but an object obtained via a class method 
> named ‘newXXX…’ is generally assumed to be returned with +0 ownership.

 Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? 
Because +new is documented to just be a shorthand for +alloc followed by -init 
on the result, so +newBlah behaving differently than +new sounds kinda 
inconsistent to me. Did I miss a serious gotcha there?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Dave]

> On 25 Feb 2016, at 17:43, Jens Alfke  wrote:
> 
> 
>> On Feb 25, 2016, at 8:35 AM, Dave > > wrote:
>> 
 Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
 have the subclass Non-ARC too.
>>> 
>>> This is not true. For example, NSView is not ARC but you can write ARC 
>>> subclasses of it.
>> 
>> I didn’t say it was impossible, but depending on what the class does and how 
>> it’s implemented can cause problems……..
> 
> You did say “you have to have the subclass Non-ARC”, which to me sounds like 
> “it’s impossible”.

Sorry, I just re-read it and it was supposed to read *may* have to…..

> And I can’t think of any way that a (properly implemented) non-ARC class 
> could cause problems for an ARC subclass. A class’s or method’s behavior 
> doesn’t change depending on whether its implementation uses ARC. Do you have 
> any actual examples of problems?
> 
> —Jens

Somewhere but it is back in the distant git-past and probably not that easy to 
find and I can’t remember why I had to do it now, something to do with 
properties and/or IVs. It may well have been possible to do it another way, but 
the easiest seemed to be to make it non-ARC too.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Jens Alfke]

> On Feb 25, 2016, at 8:35 AM, Dave  wrote:
> 
>>> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
>>> have the subclass Non-ARC too.
>> 
>> This is not true. For example, NSView is not ARC but you can write ARC 
>> subclasses of it.
> 
> I didn’t say it was impossible, but depending on what the class does and how 
> it’s implemented can cause problems……..

You did say “you have to have the subclass Non-ARC”, which to me sounds like 
“it’s impossible”.

And I can’t think of any way that a (properly implemented) non-ARC class could 
cause problems for an ARC subclass. A class’s or method’s behavior doesn’t 
change depending on whether its implementation uses ARC. Do you have any actual 
examples of problems?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Dave]

> On 24 Feb 2016, at 23:57, Greg Parker  wrote:
> 
> 
>> On Feb 24, 2016, at 2:31 AM, Dave  wrote:
>> 
>> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to 
>> have the subclass Non-ARC too.
> 
> This is not true. For example, NSView is not ARC but you can write ARC 
> subclasses of it.

I didn’t say it was impossible, but depending on what the class does and how 
it’s implemented can cause problems……..
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Britt Durbrow]

Tangentially related: 

I have a bug ( rdar://10894595 ) open on the Developer Tools (Xcode/clang) to 
add a #pragma to turn on/off ARC in the source code, for dealing with just such 
situations.

I dunno’ how much work it would be to implement… I imagine not all that much 
for somebody familiar with the internals of clang, but I could be wrong…


:-)
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Greg Parker]

> On Feb 24, 2016, at 2:31 AM, Dave  wrote:
> 
> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have 
> the subclass Non-ARC too.

This is not true. For example, NSView is not ARC but you can write ARC 
subclasses of it.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Dave]

Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have 
the subclass Non-ARC too.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Alex Zavatone]

Ok time for me to establish base test cases in very simple cases first.

Sent from my iPhone

> On Feb 23, 2016, at 6:47 PM, Quincey Morris 
>  wrote:
> 
>> On Feb 23, 2016, at 15:25 , Alex Zavatone  wrote:
>> 
>> Would it be recommended to package my ARC code with ARC turned off and 
>> package that in a framework and then link to that from the non ARC app that 
>> will need to load it?
> 
> This would be a really bad idea. :) Your code has no retains and releases, so 
> it will cause crashes unless it is compiled with ARC turned on.
> 
> Think of it this way: ARC does the retains and releases for you. Either you 
> *compile* with ARC, or you *compile* with explicit retains and release. 
> Anything else will crash. Packaging the compiled code doesn’t affect this.
> 
>> On Feb 23, 2016, at 15:29 , Alex Zavatone  wrote:
>> 
>> Are there any tools in Instruments or approaches to make sure I'm not going 
>> to destroy the universe when calling my stuff?
> 
> I don’t think you’re in danger of destroying any universes, but I don’t know 
> that there’s anything automatic to help you.
> 
> The main problem is that your (ARC) code needs to know the memory management 
> of the other (MRR) code. That means that any headers it imports from the 
> other code must not promise things that aren’t true. That includes property 
> attributes such as ‘strong’, ‘unowned’, and assumptions that ARC makes about 
> memory management based on naming. (For example, an object obtained via 
> [[…alloc]init…] is generally assumed to be returned with a +1 ownership, but 
> an object obtained via a class method named ‘newXXX…’ is generally assumed to 
> be returned with +0 ownership.)
> 
> So it’s certainly possible that the other code’s header files may be 
> non-specific enough to cause headaches in your ARC code. You’re probably 
> pretty safe in the other direction, since ARC follows the memory management 
> conventions that well-written MRR code used to use.
> 
> Perhaps your other choice is to use copies of your code, and add the MRR 
> retains and releases back in.
>  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Greg Parker]

> On Feb 23, 2016, at 3:46 PM, Alex Zavatone  wrote:
> 
> Aha!
> 
> Awesome.  That will work nicely.
> 
> Now my concern is the compiled c lib that my code links to.  Do I also have 
> to rebuild that with non ARC flags too?

The ARC flags only affect the Objective-C and Objective-C++ compilers. Plain C 
code is unaffected. Note that you may need code changes if your C code uses 
CoreFoundation types and you want to call it from ARC code.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Quincey Morris]

On Feb 23, 2016, at 15:25 , Alex Zavatone  wrote:
> 
> Would it be recommended to package my ARC code with ARC turned off and 
> package that in a framework and then link to that from the non ARC app that 
> will need to load it?

This would be a really bad idea. :) Your code has no retains and releases, so 
it will cause crashes unless it is compiled with ARC turned on.

Think of it this way: ARC does the retains and releases for you. Either you 
*compile* with ARC, or you *compile* with explicit retains and release. 
Anything else will crash. Packaging the compiled code doesn’t affect this.

On Feb 23, 2016, at 15:29 , Alex Zavatone  wrote:
> 
> Are there any tools in Instruments or approaches to make sure I'm not going 
> to destroy the universe when calling my stuff?

I don’t think you’re in danger of destroying any universes, but I don’t know 
that there’s anything automatic to help you.

The main problem is that your (ARC) code needs to know the memory management of 
the other (MRR) code. That means that any headers it imports from the other 
code must not promise things that aren’t true. That includes property 
attributes such as ‘strong’, ‘unowned’, and assumptions that ARC makes about 
memory management based on naming. (For example, an object obtained via 
[[…alloc]init…] is generally assumed to be returned with a +1 ownership, but an 
object obtained via a class method named ‘newXXX…’ is generally assumed to be 
returned with +0 ownership.)

So it’s certainly possible that the other code’s header files may be 
non-specific enough to cause headaches in your ARC code. You’re probably pretty 
safe in the other direction, since ARC follows the memory management 
conventions that well-written MRR code used to use.

Perhaps your other choice is to use copies of your code, and add the MRR 
retains and releases back in.
 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Alex Zavatone]

Aha!

Awesome.  That will work nicely.

Now my concern is the compiled c lib that my code links to.  Do I also have to 
rebuild that with non ARC flags too?

Sent from my iPhone

> On Feb 23, 2016, at 6:33 PM, Greg Parker  wrote:
> 
> 
>> On Feb 23, 2016, at 3:25 PM, Alex Zavatone  wrote:
>> 
>> Would it be recommended to package my ARC code with ARC turned off and 
>> package that in a framework and then link to that from the non ARC app that 
>> will need to load it?
> 
> Building a separate dylib or static archive is not necessary, but it might be 
> the simplest way to get the project settings correct. Writing custom build 
> flags for each of your source files is likely to be error-prone.
> 
> You can add a check to your ARC source files that will cause a compiler error 
> if ARC is mistakenly off:
> 
>#if !__has_feature(objc_arc)
>#   error This file must be compiled with ARC enabled.
>#endif
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Greg Parker]

> On Feb 23, 2016, at 3:25 PM, Alex Zavatone  wrote:
> 
> Would it be recommended to package my ARC code with ARC turned off and 
> package that in a framework and then link to that from the non ARC app that 
> will need to load it?

Building a separate dylib or static archive is not necessary, but it might be 
the simplest way to get the project settings correct. Writing custom build 
flags for each of your source files is likely to be error-prone.

You can add a check to your ARC source files that will cause a compiler error 
if ARC is mistakenly off:

#if !__has_feature(objc_arc)
#   error This file must be compiled with ARC enabled.
#endif


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Alex Zavatone]

Ok. Great. I knew there would be some scariness in there I'd need to know about.

Are there any tools in Instruments or approaches to make sure I'm not going to 
destroy the universe when calling my stuff?

I'm planning on starting by loading a placeholder one screen storyboard as an 
initial test tomorrow morn.

Is that well advised

TY Mr. Q.

Cheers, AZAVATON

Sent from my iPhone

> On Feb 23, 2016, at 6:19 PM, Quincey Morris 
>  wrote:
> 
>> On Feb 23, 2016, at 13:30 , Alex Zavatone  wrote:
>> 
>> Now, I'm familiar with the -fno-objc-arc build flags to disable compiling 
>> one file at a time, but is there any possibility to include iOS code that 
>> does use ARC within an app that doesn't?
> 
> You can mix-and-match ARC source with non-ARC (MMR) source. Just do it the 
> other way around — add -Fobj-arc to the source files that need it.
> 
> The only thing to be careful of is that pointers that cross the boundaries of 
> your ARC code must respect ARC conventions. That is, you might need to use 
> bridged retains and releases, or use casting to describe the memory 
> management characteristics of non-ARC-managed pointers.
> 
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Alex Zavatone]

Yeah, it does. I was thinking about it bassackwardsly.

Would it be recommended to package my ARC code with ARC turned off and package 
that in a framework and then link to that from the non ARC app that will need 
to load it?

Thank you, sir.  

AZ

Sent from my iPhone

> On Feb 23, 2016, at 6:16 PM, Greg Parker  wrote:
> 
> 
>> On Feb 23, 2016, at 1:30 PM, Alex Zavatone  wrote:
>> 
>> Hi all.  I'm in the middle of looking at an interesting problem on the iOS 
>> side.
>> 
>> We have our code that is ARC and uses external compiled C libs that I'm 
>> being asked to plug into another iOS project that's significantly larger 
>> than ours.
>> 
>> The intent is to run as a little service that can be launched within the 
>> other iOS project.
>> 
>> The other project that we must fit within is not ARC. Converting it to ARC 
>> is not feasible, nor our responsibility.
>> 
>> I am successfully building the iOS app that doesn't use ARC with Xcode 7.1 
>> and running on iOS 9.1.
>> 
>> Now, I'm familiar with the -fno-objc-arc build flags to disable compiling 
>> one file at a time, but is there any possibility to include iOS code that 
>> does use ARC within an app that doesn't?
> 
> Yes, -fno-objc-arc works on iOS too. Was that your question?
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Quincey Morris]

On Feb 23, 2016, at 13:30 , Alex Zavatone  wrote:
> 
> Now, I'm familiar with the -fno-objc-arc build flags to disable compiling one 
> file at a time, but is there any possibility to include iOS code that does 
> use ARC within an app that doesn't?

You can mix-and-match ARC source with non-ARC (MMR) source. Just do it the 
other way around — add -Fobj-arc to the source files that need it.

The only thing to be careful of is that pointers that cross the boundaries of 
your ARC code must respect ARC conventions. That is, you might need to use 
bridged retains and releases, or use casting to describe the memory management 
characteristics of non-ARC-managed pointers.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC code in a non ARC app. iOS

[Greg Parker]

> On Feb 23, 2016, at 1:30 PM, Alex Zavatone  wrote:
> 
> Hi all.  I'm in the middle of looking at an interesting problem on the iOS 
> side.
> 
> We have our code that is ARC and uses external compiled C libs that I'm being 
> asked to plug into another iOS project that's significantly larger than ours.
> 
> The intent is to run as a little service that can be launched within the 
> other iOS project.
> 
> The other project that we must fit within is not ARC. Converting it to ARC is 
> not feasible, nor our responsibility.
> 
> I am successfully building the iOS app that doesn't use ARC with Xcode 7.1 
> and running on iOS 9.1.
> 
> Now, I'm familiar with the -fno-objc-arc build flags to disable compiling one 
> file at a time, but is there any possibility to include iOS code that does 
> use ARC within an app that doesn't?

Yes, -fno-objc-arc works on iOS too. Was that your question?


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com