What is the importance of .pch file and what is the significance of"#ifdef OBJC"?
Also, where do we define parameters like "#ifdef IS_PRODUCTION" which are checked in .pch file.
The .pch file allows you to avoid importing common files like UIKit.h and Foundation.h. If you have those files imported in the .pch, your own classes don't need to import them.
The significance of #ifdef OBJC is so that you don't import headers containing objective-c code if you don't have the compiler set to build objective c code (hence avoiding lots of compiler errors).
You define parameters such as IS_PRODUCTION inside the target's build settings. I do it usually in "other C flags".
.pch is a Pre-Compile Header.
In the C and C++ programming languages, a header file is a file whose text may be automatically included in another source file by the C preprocessor, usually specified by the use of compiler directives in the source file.
#ifdef OBJC lets the compiler know that the code is Objective-C.
#ifdef IS_PRODUCTION is something you have defined on your own, a directive telling the compiler to do something only if this is defined, most-likely something for a PRODUCTION build.
Related
I am trying to add FBConnect to my application which includes the SBJson framework. However, when I try to compile the project I get these two errors:
Duplicate interface definition for class 'SBJsonWriter'
Duplicate interface definition for class 'SBJsonParser'
What can I do to fix this error? Thanks for any help.
Delete
#import FacebookSDK/FacebookSDK.h
In your project
I start using FacebookSDK, but then I was disappointed with it's current state and tried to use the old "FBConnect", that's how I have got the error
There are two possibilities:
you have two interfaces with the same name. Use Xcode's find in project menu option to find instances of SBJsonWriter. Then rename one of the interfaces
somehow you have managed to import the .h file twice. Check to make sure you always use #import and not #include.
A bit more info on #import/#include:
include blindly includes the file at the location of the #include statement. This means that if you #include a file twice in your .m you will get two copies of the file. Almost all traditional C #include files have something like the following bracketing all the content:
// some_file.h
#if !defined SOME_FILE_H
#define SOME_FILE_H
// entire content of #include file
#endif
he above is sometimes referrwed to as an include guard macro.
In Objective-C, if you #import a file, a check is performed by the compiler to make sure it has not already been imported. Consequently the guards are usually omitted. So if you #include a file that was supposed to be #imported, neither check will be done and you will sometimes get duplicate definitions.
I'm using a SDK in one of my projects and when adding in the libraries etc, I get an error from this line of code, which is from inside a .h file. I cannot change the .m since its not available to me. Its inside .a (lib)
-(enum scanDeviceID)ID;
And the error message is:
Semantic Issue
ISO C++ forbids forward references to 'enum' types
Are there any compilier/build setting that I can modify to make this work?
Failing that, I know very little C++, is there something on the line of code I can change to make it work?
The line of code says that this method returns an element that's named in the scanDeviceID enum. The problem is that the compiler doesn't see a declaration of that enum. Somewhere in a .h file you should have that declaration. Importing the file should fix it.
I have the following file testf.h:
#ifndef TESTF_H_
#define TESTF_H_
int test(int what){
return what;
}
#endif
I included/imported it in TestAppDelegate.h (which is used for other .m files in my xcode project). I get a duplicate symbol error. If I included/imported testf.h in a .m file that is never included/imported in other files then it works fine. So it seems like the #ifndef/#define/#endif has no effect. Is there anyway to go around this?
Thanks
This is a function definition, it belongs in a c, cpp or m file.
This popular trick with #defines will protect you from compiler errors (typically to survive circular #include dependencies. ) It will not protect against a linker error. This is exactly why people put declarations in h files and definitions in c (or m) files.
Including function definitions (as opposed to declarations) in header files is generally a bad idea and now you know why. You want two separate files, the header would look like this:
#ifndef TESTF_H_
#define TESTF_H_
extern int test(int);
#endif
And then a .c file (or possibly a .m file if you want to use Objective-C rather than plain C) like this:
int test(int what) {
return what;
}
The header file will let the compiler know what test is, what it returns, and what arguments it should take; that's enough information for the compiler to arrange a call to test; that's actually more information than the compiler needs but some of us like our compilers to do some error checking. The C source file will (after being compiled into a object file) let the linker know what code the test symbol resolves to.
Right now you're ending up with multiple globally visible instances of the test symbol, one for every file that has included your testf.h.
The other option, for a simple function, is to declare it inline:
inline int cNorm(float _amp) {
return 42;
}
I have many constants in my application used by many classes of my project. These constants have to be set at compilation time (they are not modified later).
For now, I use #define statements at the top of each classe that requires the constant. The problem is that I have to repeat these statement in each classe which requires the constant.
I plan to define all these constants in my main.m or in another .h imported by main.m but I think it is not a good idea.
-> Is there a XCODE / IOS mechanic or file made for that purpose ?
-> If not, is it a good idea to define the constants in my main. ?
Thanks for you help
kheraud
You can write all constants in any .h file , then you can import that file in your projectname_Prefix.pch file .
then you don't need to import file in any other source file . its directly get imported .
you can save them in your *_Prefix.pch then they will apply for all classes without importing another class.
Generally the best way to handle shared constants is to declare them extern in one or more dedicated .h files, and then define them in corresponding implementation files. That way you'll be guaranteed to only have one copy of each constant in your binary, unlike with a #define.
You can provide target-wide compiler defines in Xcode by adding them to the Preprocessor Macros build setting. For example, this might let you create a free Lite version of your application by creating a target for it within your project, then adding a LITE define in the Preprocessor Macros.
See this question for more on this.
This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.
Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.
What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.
The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.
You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.
So, is the way I view linking libraries correct? If , not can someone correct me on this ?
Basically, you are correct.
Compiling the source code of a library produces one object file for each of the source files (in more than one, if compiled multiply times against different architectures). Then all the object files are archived (or packaged) into one .a file (or .lib on Windows). The code is not yet linked at this stage.
The .h files provide an interface for the functionality exposed by the library. They contain constants, function prototypes, possibly global declarations (e.g. extern int bad_global;), etc. -- basically, everything that is required to compile the code which is using the library.
.h files do not 'communicate' with object code in any way. They simply provide clues for the compiler. Consider this header file:
// library.h
extern int bad_global;
int public_func(int, const void*);
By including this file in your own code, you're simply telling the compiler to copy and paste these declarations into your source file. You could have written declarations for OpenCV library and not use the headers provided with it. In other words, you're asking the compiler to not issue errors about undefined symbols, saying "I have those symbols elsewhere, ok? Here are their declarations, now leave me alone!".
The header files need to be included in the search path in order for compiler to find them. You could simply include them via the full path, e.g. #include "path/to/file.h", or supply an -I option for your compiler, telling him where to look for additional headers, and use #include <file.h> instead.
When your code is compiled, the declarations in header files serve as an indication that symbols your code is using are defined somewhere. Note the difference between the words declaration and definition. Header files contain only declarations most of the time.
Now, when your code is compiled, it must be linked in order to produce the final executable. This is where the actual object code stored in the library comes into play. The linker will look at each symbol, function call, etc. in your object code and then try to find the corresponding definition for each such symbol. If it doesn't find one in the object code of your program, it will look the standard library and any other library you've provided it with.
Thus, it is important to understand that compilation and linkage are two separate stages. You could write any function prototypes at all and use them in your code, it will compile cleanly. However, when it comes to the linking stage, you have to provide implementation for symbols used in your code, or you won't get your executable.
Hope that makes sense!
The .a is the compiled version of the code.
The header files provided with a library are its public interface. They show what classes, methods, properties are available. They do not "communicate" with the binary code.
The compiler needs the headers to know that a symbol (a method name for example) is defined somewhere else. They are associated with the right "piece of code" in the library binary later during the "link" step.