This is about ARC in IOS 5.
Suppose it is ARC enabled and I still use retain release etc in code , are there any risks ?? or will it be handled automatically ??
I know that ARC can be avoided for specific files. But in this case I have not done anything to remove ARC on this file. This file is now a mixup ( with release for some allocations and without release for some allocations ).
What are the risks expected in such an environment?
Thanks for any help !
--mia
You cannot use retain or release in ARC enabled code. It's simply not allowed - the compiler will error out. If you are not explicitly indicating to the compiler that a file should not be compiled with ARC enabled (using the -fno-objc-arc flag) and you call release your code won't compile.
Hope that helps!
Suppose it is ARC enabled and I still use retain release etc in code
You can't. You will get a compiler error if you do.
Mia, that is actually untrue. If you compile from the command line using Clang and tell it to use ARC with the flag -fobjc-arc you can get away with [object release], etc. It appears to be a xCode thing that blocks the use of these memory management calls.
However, like lxt was suggesting you will NOT be able to call release / retain if ARC is enabled in an xCode project unless you explicitly add the -fno-objc-arc as a compiler flag for the file in your project the requires it.
Related
i am using xcode 4.4.1 for iOS target 5.1
i've started my project using ARC, and in the middle of the project I've added some non-arc thirdparty source to my project.
at this point, i've decided to try refactoring in xcode and an error occurs.
it comes from one of my original source code.
i have a property of (nonatomic, weak) and i've synthesized it ==> synthesize of 'weak' property is only allowed in ARC or GC mode.
I am puzzeled - i am using arc and it complains that it is only allowed in arc??
At the moment, i've refactored the thirdparty app from other project and copied it for my project to work, but the above is a question I'd still like to understand why .
Thanks!
(by the way, when i do convert to arc, it says that the target currently uses ARC)
It sounds like the issue is you've already set it up as an ARC project and your are for some reason trying to convert it again. I can only assume that the process doesn't expect therefore weak references at this stage. If you set them to Assign then convert to ARC you will see that it then suggests you change them to weak.
I had the same symptom using Xcode 4.6.3 targeting iOS 6.1. I brought in a non-ARC class from another project and converted it via the Refactor menu only to have subsequent builds fail on a pre-existing class with the error you saw (“synthesize of 'weak' property is only allowed in arc or gc mode”).
The project properties clearly said it was still an ARC project but the compiler seemed to have forgotten this was the case for the class in question.
I got around the issue by setting the property to 'strong' and converting that class to ARC via the Refactor menu. Unsurprisingly it told me no changes were necessary but did offer a Save button which I clicked. I was then able to change the property back to 'weak' and compile the project. (I'm presuming some metadata got out of synch somewhere along the way.)
EDIT: I eventually had to 'Refactor' other ARC-compliant classes to ARC as although they compiled they generated warnings and caused crashes in my app. I think the moral of the story is that including your whole project in the refactoring might be safer...
instead use:
#property(nonatomic,assign)
*note - This is not the same as weak, but very similar. Weak also sets the object to nil, assign does not.
I'm using the Accessorizer code helper for xCode. I seem to have it configured correctly and it is generating property statements and synthesize statements fine.
It is not generating the release statements however when I choose the dealloc action.
If I choose dealloc against an NSTimer, it does generate the [myTimer invalidate] statement, but not the release statements, so it seems to be triggering the dealloc action, but the action isn't configured properly? and so no release code generated.
Has anyone come across an issue like this using accessorizer?
Amazing how you find an answer just after asking a question.
For anyone else that has this issue, turn off ARC Aware in the Accessor Style TAB of the Accessorizer application. (yes seems bleedingly obvious in hindsight, was stupidly thinking it might be aware of the xcode project settings and ARC isn't on for this project, but its really just a 'dumb' editing tool that operates only on the input text i.e. not integrated to xCode).
The things we have to go through to do something that anyone who codes objective C for more than half an hour would have made the first feature of a new IDE. (automatic generation of property/synthesize etc.)
Actually i came to this question when i was trying to add some classes that have been made upon ios prior to IOS 5 and these classes doesn't having ARC and the project i am trying to add is made upon the IOS 5 and it give me the compile time error related to ARC the classes having suck kind of information that if i try to remove the release/retain then it start behaving irregular.That is my problem, Now come to question i want to know that is there any way so that i can mark those classes not to use ARC so that the newly created classes that having base SDK ios5 compile with ARC and i mention not to use ARC simply compiled with their retain/release values.That is the only way i have left i think for making properly this app.
Any idea how i can use those classes that is having base sdk prior to ios5.
Thanks,
the image below will show you how to do it.
-fno-objc-arc flag to disbale arc
-fobjc-arc flag to enable arc
Go to your project settings, under Build Phases > Compile Sources
Select the files you want ARC disabled and add -fno-objc-arc compiler flags. You can set flags for multiple files in one shot by selecting the files then hit Enter key.
Go to Issue Navigator -> Validate project settings -> Perform changes. In this way Xcode automatically remove release and retain keywords from whole project and convert into ARC compatible.
In a ARC enabled project, is there a way to add the -fno-objc-arc tag programatically in the code it self.
So i could give my source files to someone else, and that person need not add the -fno-objc-arc manually.
I assume this is because you want to distribute your project as a re-usable library that can be used in other projects regardless of whether they use ARC?
I don't think you can add the flag to the source to tell ARC to ignore the file (at least I've not found a way yet), but you can detect if ARC is enabled within the file using
#if __has_feature(objc_arc)
...
#endif
You could use this to raise a warning, by saying
#warning This file is not ARC compatible, add the -fno-objc-arc tag
But an even more elegant solution is to use this feature to automatically branch your code at compile time so that it works on both ARC and non-ARC builds.
I wrote a simple re-usable header that can be pasted into the top of your source file or included in the project as a standalone header file:
https://gist.github.com/1563325
This provides a bunch of macros to use instead of retain, release and autorelease methods so that they can be automatically stripped for ARC builds. For an example of how this is used, check out iRate:
https://github.com/nicklockwood/iRate/tree/master/iRate
It only takes a few minutes to convert a class file this way.
No - not in the code itself. This is stored in your project file, so if you send the entire project to someone else it should work. However, you can't just send them a few classes and have that work (it needs to be the entire project).
I'm using Xcode 3.2.3 and iPhone SDK
So I'm trying to debug a UIView subclass, I hit a breakpoint in an overridden method and I can't see any symbols in either the GUI or gdb, just globals and registers.
This is what I see:
(gdb) po self
No symbol "self" in current context.
Yet when I set a breakpoint in a UIViewController subclass, all the symbols are there:
(gdb) po self
<MyViewController: 0x5c18ae0>
Current language: auto; currently objective-c
Some things I've tried:
clean all/rebuild
restart Xcode
change between debug and release
config these options in Project
settings:
GCC_DEBUGGING_SYMBOLS = All
Symbols DEBUG_INFORMATION_FORMAT = DWARF, DWARF w/ dSYM File
BUILD_VARIANTS = normal, debug
threatening Xcode by swearing at it and typing
rm -rf /Developer into a root bash prompt
Please help, my fingers are bleeding from debugging with NSLog
I experience this bug often. My workaround is typing the bt command on the gdb console, it then automagically sorts itself out and starts recognizing symbols in the current context.
So changing from Debug to Release did the trick and I have all my debug symbols.
I think it's just a bug in the 4.0 SDK.
Hmmm, tried to repro this in 3.2.3 and SDK4 Final with no success -- able to debug UIView subclass as expected. Is this occurring using one of the beta releases?
Happening to me, on a non-beta release. I just noticed that it only occurs when calling a class-defined method, ie (+) not (-)
I wouldn't mind not having a "self" pointer, but it also seems to wipe out all local variable displays in the debugger, and that is just wrong.
MTS' method worked for me. Changing from debug to release fixes this issue. How strange. I can disprove software evolved's theory, as I experience the error inside an instance method.
in gdb type bt.
If you see self=<value temporarily unavailable, due to optimizations> anywhere it's because xcode has been set to be optimized.
Go to the build settings and type optimization.
If optimization level for either debug or release is set to Fastest that's causing your issue.
Release should be left at fastest so your code run well when building for distribution. It's better to change your Build Configuration in Scheme.
opt+click the Run button. On the left click Run YourAppsName.app, then Info and select debug.