I am facing an issue, Currently i am using xcode 5.0, when i am importing clasess from prefix.pch then it dose not give suggestions on appdelegate.h file. But it gives suggestion on other view controller's. I have googled about it and find if we define macros in prefix.pch then this problem occurred. Still after removing the macros it did not give suggestion on appdelegate.
Suggestios means if i try to write
#property(strong,nonatomic) UINavigationController *navControler;
After writing #property(strong,nonatomic) UINav xcode did not give suggestion. But if I remove all the import statement and macros from prefix.pch file then xcode give suggestions on appdelegate.
From my point of view, rather than finding a workaround, I want to put some light on the actual problem.
So when you want to add something in .pch (pre compiled headers), it means you want to use the content of files before your program is actually being compiled & build. In simple words the headers included in pch acts as a stub code, a base code or may be a code that is meant for using as it is intact.
So if you have already included appDelegate.h file in .pch & writing some code in appDelegate.h file, then the compiler is trying to use 'appDelegate.h` from .pch as a pre-compiled information. And may be it is resulting in a indefinite sate of Xcode background processing, which is not allowing to show the drop down helps in the file which is already pre-compiled.
To me it looks like app delegate.h in .pch is not the right place. Where ever you want in your program, you can very well include appDelegate.h file. However it is also a signal of bad Class Design approaches.
Also, if you want to add #define statement & other macros in .pch then it is not the right approach. The right approach is :
Make a simple .h file, say constants.h
Add all your #defines & macros here in constants.h file.
Add the #import "constants.h" in your .pch file.
That should solve your problem.
Hope that helps.
Related
I included in my iOS project a widely used UIImage category to handle PDF, and got some compilation errors. This raised several questions.
Q1: Why would Xcode (or actually the LLVM compiler) not give any warning on a header file that is including itself ? I don't know if this has a special meaning in C or Objective-C that would prevent it from being seen as a typo ? In my example, I believe that a mistake was made and Foundation.h was probably the intended include:
In the category file NSString+MD5.h I found:
#import "NSString+MD5.h"
#interface NSString(MD5)
- (NSString *)MD5;
#end
The corresponding .m does not include the .h. (Link is "Here")
Q2: I got the compilation error because I started from an Apple project that doesn't NOT include the Foundation framework (AVCam 3.1 for iOS) ! So NSString was undefined. I'm a bit puzzled by this but linking with the foundation framework in xcode is like including all its headers ? I would expect again some warning at least ?
Thanks for any explanation on this probably very basic C topic.
First of all, in Objective-C, we #import, which is different from #include. While #include will attempt to include any file you list, #import will never double import any file. I imagine that this explains why there's no problem with a .h file trying to #import itself. It's not correct for the file to import itself, but because it's an #import, it won't actually cause any issues.
As for the .m file not importing it's .h, in this case, it doesn't actually have to. It's a good idea, out of habit, to always import the .h file, and any files generated by Xcode will do this automatically, however it's not always necessary. It's only necessary when the .h file has declared something that the .m has to know about. For example, a #property that you intend to use. You've declared it in the .h so it'd have public access, but if you intend to use it in the .m, the .m has to know the #property has been defined. Additionally, if you've #imported some files in the .h that the .m needs and you don't want to import them again in the .m, you'd need to import the .h (although it's generally going to be better to just import them in the .m.
Here, the .h simply defines the exists of a method that returns an NSString * and is called md5 and takes no arguments. This means that anything importing this .h file can call this method and Xcode won't complain about the md5 method not existing. The corresponding .m file implements a method that coincidentally matches the one the .h defined. If you deleted the .m file, your program would almost certainly still compile just fine... but you'd hit an unrecognized selector exception when you go to the point that md5 was being called--despite Xcode not complaining about it. With the .m in the project, this exception isn't hit. The program figures out at run time which method to execute.
And finally, as for not including Foundation.h, every iOS project created by Xcode has #import Foundation.h and #import UIKit.h in the precompiled header file. Any other file in your project with these imports is just redundantly importing the file, as it's already been imported by the .pch, but because of the magic of #import (vs #include) it's not actually double imported.
If you're working with an iOS project that doesn't have these imports in your .pch, your best bet is to just stick them in the .pch.
If you're opposed to this for some reason, the best way to fix this md5 file is with this simple line:
#import Foundation.NSString;
The new syntax in Objective-C in Xcode 5 is #importto import a framework.
See question for details. Advantage is that you don't have to include the framework in project avoiding linker errors, you don't need to add quotes and .h to just the name of the framework, it is faster for precompiled headers, and you have a namespace that protects you from accidentally renaming a symbol. All nice additions.
My question is, for your own files, for example MyFancyViewController.h, do you continue to use #import or does #import completely replace it? Also, can I define my own modules easily? Just looks more messy having both syntaxes in the same file.
for you including of your project files do you continue to use #import or does #import completely replace it?
#import, so far, is for Apple frameworks only, so at the time of writing you still have to use #import for anything else.
The good news is that, if you opt-in, any #import will be implicitly replaced for you by the compiler, so you don't need to convert your previous code to benefit from modules.
Also, can I define my own modules easily?
Yes and no.
Yes, it's easy, but...
...no you cannot, since this feature is currently not supported for non-Apple frameworks.
To define your own module - if you could - you would need to do:
export MyAwesomeModule:
public:
// methods and whatever you want to export
#import is for official frameworks only. For MyFancyViewController.h continue use #import.
Default file:
#import <Foundation/Foundation.h>
#interface MyClass : NSObject
#end
My understanding is pre-compiled headers are included in every file. Why doesn't this import just go into the pre-compiled headers?
There is no guarantee that every project have a .pch file that import Foundation.h so Xcode need to generate it to make sure new files always compile.
Also some people think it is good style to include header even it is already included in .pch file. Because you know exactly what headers are needed by this file. It also allow people to disable prefix header if needed.
My Xcode 5 doesn't appear to be including it in every class (it is included in the .pch file). I agree with you that this makes more sense than including it everywhere. The answer to your question is probably "an oversight on Apple's part" :)
.pch
#ifdef __OBJC__
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#import "thing.h"
#endif
I have a pretty large project I'm trying to debug and I have a suspicion the problem is in thing.h
From what I understand the .pch file is included in EVERY .m and .h in the project.
Is it possible to have it not included in just one or two files? For debugging I would like to not include thing.h in just one test file, but removing it from the .pch causes a cascading nightmare across the project.
This is a really old question but I just ran into this issue. I was able to solve the problem by wrapping the pch file with a ifndef SOME_NAME. Then in the project settings on each specific file I wanted it to not be included I added a compiler flag of -DSOME_NAME=1. Hope that helps someone in the future.
I am just wondering, is it good practice to include commonly/mostly used header files in .pch file?
e.g Most of files required below headers
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
So instead of each file should have, is it good practice to add those in .pch file?
.pch file
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import <MostlyUsed.h>
#endif
I found some disadvantages of this,
1) Dependancies get hidden.
2) Source files can not be copied directly.
It will be great if you guys provide some inputs on this.
Thanks
Yes you can do it.
Even it reduces compile time.
An Extract from In Objective-C, importing same headers in every class make compile time longer?
In general, newly-generated iOS projects come with this functionality,
which is called a precompiled header or prefix header, and is a file
that has the extension .pch.
You can throw all the headers you want in there and Xcode will
pre-compile it before it builds anything else, and use it to compile
the other compilation units in your project (e.g. .m files).
Using a precompiled header may or may not increase compile time; in
general, it reduces compile time, as long as you have a lot of common
headers and/or a lot of source files.
However, it's not necessarily good practice to treat the pre-compiled
header like a big dumping ground, as your compilation units can form
implicit dependencies on all sorts of stuff when you may want to
enforce loose coupling between components.
It is certainly a good practice as it reduces compile time and code is lot more manageable by doing so.