I have been using AppCode recently to circumvent an issue with Xcode in refactoring, and AppCode has nailed for me quite few "oups'es" whereby it warned me of un-released but retained object refs ... sniffing them out correctly through #property specifications too ! (not exactly what I was looking for mind you :) ), but a great help.
I was wondering if such a feature is available in Xcode (am using 4.1.1), and if yes how/where to enable it.
You can perform that kind of check using static analyzer - choose "Analyze" option from Product menu (or shift-cmd-B shortcut)
You could change the mode of analysis for 'Build' to deep under project build settings. By default its set to shallow.
Its located under the heading 'Static Analyzer - Analysis Policy'
Related
Every few months, I get the same problem of a ViewController not getting dealloced because of not using weak-self in a block.
Is there any way of making Xcode warn me about this?
Thanks.
This might help -Warc-retain-cycles
Also, if instead of Build, you choose Analyze in Xcode, this will give you more information about bad practices in the code which includes information about using weak variables.
Another level further is to use Infer, a static analyzer for iOS/Android that Facebook open sourced: www.fbinfer.com
Also, see: http://fuckingclangwarnings.com/ for other warnings. I just have '-w' set on my project to get all the standard warnings
Let me start by saying I am not sure if this belongs here or at Super User. I started here.
Now, I am a very tidy person, and I like collapsing methods so that I can get around very easily. However, one thing that aggravates me is that all my #synthesize commands are always there. I can see no way to collapse them. (I have over 50 properties to synthesize) Is there a way I can hide these commands, while not messing up my build.
Thanks.
Unfortunately, from "available features" perspective, XCode is a very old IDE. Therefore no foldable code regions - see detailed discussion Xcode regions
Also note that with the latest compiler (LLVM 4.0), declaring #synthesize is optional. You can enable/disable it in compiler settings in your project settings.
However, if you are using GCC or an older LLVM version (for whatever reasons), this is not possible.
Edit:
After rereading your question... having 50 properties in one class smells very bad. Consider splitting your class into several smaller classes.
You can also put the #synthesize commands to the end of the #implementation file.
Since Xcode 4.4 you don't need to #synthesize properties if you don't want another name for it — it uses auto synthesise.
This might be a silly question, but I just wanted to know. I want my code to detect if ARC is enabled, programmatically. How do I do that? Is there is any flag that I could check? Actually the problem is that, I have written an open-source library. I have used release and retain in it. if some one else uses my library files using ARC enabled, I dont want them to get any errors. how do I achieve this? or is there any possible ways I can provide any tools to compile my library before using it?
#if !__has_feature(objc_arc)
//Do manual memory management...
#else
//Usually do nothing...
#endif
This is of course a compile-time check, you cannot check for ARC at runtime.
An alternative would be to set the -fno-objc-arc compiler flag for your files that use manual memory management in a project that otherwise uses ARC.
Whether you want to bother with this at all or just use ARC everywhere depends on how backward-compatible you want/need to be. Code that supports both ARC and MRC can get quite hard to read and maintain.
You don't detect it programmatically, it operates based on translations. That is, it is not like Garbage Collection -- which is process-wide, required all linked libraries to support (and implement it correctly in that mode). You can have some files compiled with ARC, and some without.
However, you can detect it at compilation.
As far as the distribution of your library: I would not bother with a translation based system, where ref count ops are conditionally enabled. I would (personally) just support one model (MRC in your case, until you choose to migrate it to ARC), then expect people to link to the library, or if they compile it in a target they configure, to disable ARC. Conditionally enabling/disabling code based on the presence of a feature is asking for tough bugs, particularly when it's likely to affect 9% of your library's lines of code.
NO, you can't, Xcode would not compile in ARC projects if your source uses retain-release
I have gotten this error on several occasions and am unclear as to what causes the error in general. After looking for over an hour on stack overflow and google I still don't have an answer. Could someone help?
I've seen several specific answers but nothing that says why the error happens, only "do x", or "do y".
I haven't included code yet because I want to know the reason that this error happens in general so I can fix my code in the future whenever I get this error.
There are lots of reasons it could happen, but generally it's saying that at the line of code it flags, it doesn't see any evidence that the selector you are referencing is in the interface of the type it thinks the object has.
In this example,
No visible interface error
They declared operandStack with the wrong type.
In this one
http://www.raywenderlich.com/forums/viewtopic.php?f=2&t=3312
They had a typo in the selector name
Any chance you are on Xcode 4.2 (or less), running code that was written on Xcode 4.3? In 4.3+ Xcode doesn't require you to declare private methods at all, it just assumes that methods written in the implementation file (without declarations in the interface) are private. But in Xcode <= 4.2, this will throw an error and those methods need to be at least declared privately
I just had this problem; mine was caused by me setting the method as a class method rather than an instance method. Very silly.
Another reason can be when using categories in libraries and you haven't set -ObjC (or -all_load) in the Other Linker Flags
Another common error ist to forget to write [someInstance setSomeValue:3]; instead of [someInstance someValue:3] (<- wrong). That what happened to me.
When I have run into this problem it turned out that Xcode had not reindexed files after changing Git branch. The solution is Delete Derived Data.
Using Xcode version 10.0 File -> Workspace Settings...(or Project Settings...) -> click on the little green circle and manually remove all files in DerivedData folder
I had this problem with NSSavePanel -beginSheetModalForWindow::, which obviously exists. I tried doing a clean rebuild as well as deleting the DerivedData, but no luck. I had copy-pasted and then modified, but I commented that out and typed out the call to -beginSheetModalForWindow and it started working. As far as I can tell I did not have any mistakes in the original call.
Is there a way to make XCode warn for unreleased objects?
It may be useful for classes with lots of objects and I forgot to put [obj release]; in the dealloc method.
You can use the Analyze tool ("Build and Analyze" in Xcode 3), which does static analysis and points out where you have unreleased objects. More detail here: Build and Analyze: running the analyzer within Xcode
It's not a compiler warning because it's valid Objective-C (though bad Objective-C), but if you use the static analyzer instead of the compiler, it can often detect cases where an object is leaked. (You still have to use the compiler to run your app, of course.)
I would recommend that you change your build settings to let it run everytime you compile your software.
How to turn it on:
Select your project - Build Settings - Build Options - Run static Analyzer [YES]