In reference to this related question on stackoverflow:
If you create a constants file, how do you "link" to it in your target, so you don't have to
#import "Constants.h"
in every file you use constants?
You really should be using #import "Constants.h" every place you want to use the constants within it; Objective-C is a C-based language.
Furthermore, you aren't "linking" to it either when you put an #import directive in your code or if you put one in your prefix file. In both cases, the contents of the file are included in the text stream fed to the compiler by the preprocessor.
Finally, you shouldn't generally add random things to your prefix file. (Panagiotis Korros referred to this as "your pre-compiled header file," but that's slightly incorrect; your prefix file is used to generate the pre-compiled header file.) If you keep your build settings consistent across projects, and use the same name for your prefix files across projects, Xcode will actually cache and re-use the precompiled versions for you very aggressively. This is defeated by putting project-specific contents in them.
You can put the import line in your pre-compiled header file.
That is the .pch file named after you application name.
When I use the constant in more file inside my application, normally I use the .pch file (find it under "Supporting Files" folder).
Into my .pch file I insert the constant, for example:
static const int NAME_CONSTANT = 200;
and use NAME_CONSTANT into all file inside my project without import never file because the .pch is pre-compiled header file.
Related
The JavaVM framework contains a sub-framework, JavaNativeFoundation framework. This sub-framework contains a header file, JNFRunLoop.h, that I need.
According to Apple documentation:
#import <Framework_name/Header_filename.h>
In both cases, Framework_name is the name of the framework and
Header_filename is the name of a header file in that framework or in
one of its subframeworks.
#import <JavaVM/JNFRunLoop.h> does not work (JavaVM/JNFRunLoop.h file not found).
I tried adding the sub-framework headers to the header search path, and while this allows me to import it, it gives a compile-time error which is mentioned in the documentation:
The umbrella header files and the subframework header files contain
preprocessor variables and checks to guard against the inclusion of
subframework header files.
I ultimately need to do this:
[JNFRunLoop performOnMainThreadWaiting:YES withBlock:block];
which won't work until I can import that header file. Any ideas?
The authors of the library have put that guard on purpose. Are you sure you are doing the right thing?
If the library allows modifications the right way would be to take it and adapt it to your needs.
If you need a quick and dirty way to call that method, you can try to declare it inside your ".m" file like so:
#interface JNFRunLoop
+ (void)performOnMainThreadWaiting:(BOOL)w withBlock:(void (^)(void))b;
#end
(it must match to how it is declared in JNFRunLoop.h in terms of name and parameter types)
After this declaration it becomes available for calling. Note that this won't work, if the library requires some special initialization steps, or if that function name is mangled in their binary or not present their.
I'm trying to understand what really happens at compile time and runtime with imported files.
Does #import "file.h" directive essentially copy and paste the entire file.m into the current file? Or does it just specify that file's location and create the necessary attributes as they are instantiated?
The imports are handled by the preprocessor in C, C++, and Objective C, which creates one large file for the compiler. Every *.m, *.c, *.cpp file will each get all of the imports.
You can compile code on the command line with the -E flag to see the result after all the #imports are added.
Additionally, this question goes into some detail about #include vs #import, so it might give you more insight:
What is the difference between #import and #include in Objective-C?
As you can image, having lots of extra imports slows compilation. Jetbrain's AppCode has a feature that will optimize imports:
http://www.jetbrains.com/objc/features/
Does #import file.h statement essentially copy and paste the entire file.m into the current file?
It is not a statement, it is a preprocessor directive.
You're missing quotes or angle brackets around the file name.
#import "file.h" does indeed copy the whole file.h file in place of this directive into the current file. It doesn't, however, do anything with file.m.
In my project I have a requirement to create separate file for all constants that i am using in separate classes in the same project.
I seen some examples but they are saying about creating in '.h' file and again they are implementing them in '.m' files. But i need only '.h'file to create all constants and i have to use all those constants by importing that '.h' file in every class of my project.
ADD a new file.
Right click on the file inspector
choose New File
The pop up window select ios>C and C++>HeaderFile[Figure]
Give name Constants
Add #define OK #"OK"
Go to View Controller include file in header #import "Constants.h"
OR Define in pch file ,so that all View controllers can access the file
In viewDidLoad NSLog(#"%#",OK);
You can create .h file and use #define to create constants and then include your file to prefix file of your project. Though I prefer to use extern constants which you declare in .h file and define in .m file. This help to track possible warnings in your code at compilation time.
You've pretty much answered your own question, to the point where I'm not sure exactly what you're asking - you can just create a header file (.h) with your constants, and import it into your other classes. You don't need to create a corresponding implementation (.m) file. If you're using your constants throughout your code you could import them in your prefix header and have them automatically available.
I reference the FBXSDK from a number of files, but one in particular causes this error to crop up. The particular header just imports the fbxsdk like so:
#import "fbxsdk.h"
I also reference it from the .mm file, and compiling with just the .mm referencing it works fine. It's only when I import in the header that the fbxsdk brings up errors like this:
include/fbxfilesdk/fbxfilesdk_memory.h:67:15: error: new: No such file or directory
and a bunch of expected '*' before '*' errors. I'm guessing it has to do with the compile order, or it's compiling the fbxsdk with a different rule set after reading the initial header? I'm still learning how to work with different compilers and libraries, so any suggestions or clues as to where to look for a solution would be helpful.
Working with Xcode, in a mix of Obj-C++ and C.
Chances are you are trying to import fbxsdk.h from a .m file, not a .mm file. If you're importing fbxsdk.h in one of your own .h files, you need to be sure that your own .h file is only imported by .mm files, not .m files.
Is there a difference between importing something (e.g. #import "JSON.h") into the header file versus the implementation file?
If you #import it in the header, then everything including that header gets it. You may find that useful, in that you don't have to #import it again in other places, but my preference is to #import things only where necessary, to minimize dependencies and make builds faster.
I think if you do it in the header file, you save your self some trouble later on in case you reference a class which is defined in the imported file.
In other words, if you import "JSON.h" in the header file, and there's a JSON class (hypothetically) that you will use in your header file (in the interface), then it would save you from having to do the #class directive at the top. Then your implementation file will also be fine since it would import the header file, which itself imported the "JSON.h" file
Basically I think it would be neater and would be more like objective-c if you import the required files in the interface file (.h). As you've probably noticed, interface files are usually short and concise, allowing you to get a quick glance at what a certain class is about and what it does. If you import your files there, you can also see what files/classes it relies on more easily, saving the implementation file (.m) for the actual 'meat'.