That's where we are going. The reason we went with shipping a binary
.framework is because of Xcode 4 and it's limitations regarding
project template definitions (not supported nor documented) - there
was no way to link to a subproject. With cli tooling we have more
control.
On Thu, May 10, 2012 a
On Thu, May 10, 2012 at 5:32 PM, Shazron wrote:
> D'oh - we can't have dual support of course, since this is compile
> time and we ship a built binary for the framework. We'll have to turn
> it on, and require ARC. The problem is, all the plugins will need to
> upgrade as well.
>
We should stop
Resurrecting this. My latest comment (duped below):
https://issues.apache.org/jira/browse/CB-274?focusedCommentId=13272771&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13272771
---
D'oh - we can't have dual support of course, since this is compile
time and
I'd rather not do #ifdefs and go whole hog on ARC. If we go ARC we
can't support iOS 3.x (see my previous email).
The #ifdef you would use:
#ifdef __has_feature(objc_arc)
NSLog(@"ARC eh");
#endif
On Thu, Mar 8, 2012 at 12:16 PM, Patrick Mueller wrote:
> On Thu, Mar 8, 2012 at 14:14, Shazron
ARC in a nutshell is the compiler automatically adding retain/release
code [2]. Also, weak references etc, @autoreleasepool built into the
language.
Caveat: Cocoa only. CoreFoundation based frameworks cannot use ARC (so
for example AddressBook stuff the memory still needs to be managed
manually).
+1 going exclusively ARC
On 3/8/12 12:39 PM, "Jesse" wrote:
>ARC benefits, less code, cleaner code, simpler code
>ARC downsides - anal memory management folk won't be able to use it (
>non-ARC applications cannot load an ARC library, it is all or nothing. )
>
>The only way to support both is to
ARC benefits, less code, cleaner code, simpler code
ARC downsides - anal memory management folk won't be able to use it (
non-ARC applications cannot load an ARC library, it is all or nothing. )
The only way to support both is to do both ... ie conditional code, #ifdef
bs that I personally think w
What are the down-sides, if any, to moving to ARC? Potential for not being
"as optimized"? Not sure how much that matters to the typical
lists-n-buttons app that most Cordova apps are.
And up-sides? Less/cleaner/easier code?
On 3/8/12 12:16 PM, "Patrick Mueller" wrote:
>On Thu, Mar 8, 2012 at 1
On Thu, Mar 8, 2012 at 14:14, Shazron wrote:
> Ref: https://issues.apache.org/jira/browse/CB-274
>
> I say we go ARC.
>
I think we need to support ARC. The question is do we need to support NOT
using ARC as well.
Presumably there's some pattern of leaving your retain/release calls in the
code,
Ref: https://issues.apache.org/jira/browse/CB-274
I say we go ARC.
What is ARC? (Automatic Reference Counting)
Automatic Reference Counting (ARC) for Objective-C makes memory
management the job of the compiler. By enabling ARC with the new Apple
LLVM compiler, you will never need to type retain o
10 matches
Mail list logo
