I'm currently having some linker problems when trying to compile an Objective-C program and think that the reason why I can't figure out the issue may be due to ignorance as to the compiler process.
Would it be possible for somebody to give me an overview of the steps taken during compilation?
This is as I currently understand the process:
The compiler copies the contents of any included .h files into the file that it was defined in. The compiler does not keep track of whether a .h file has already been included, so it may be included within a project multiple times.
Any .m files are compiled to C equivalent code (which are in turn compiled to object code).
The linker produces links between the declarations made in the .h files and the appropriate functions within the object code. The appropriate functions are determined by looking for them in a .m file of the same name.
The object files are connected together to form the executable, making sure that the main function is situated at the entry point of the executable. Any declarations are then presumably deleted to save space?
Assuming this is correct (which it may not be), this would presumably mean that you should never #include .m files because you will likely end up with multiple method definitions which will cause the linker problems.
Thanks for any illumination anybody can bring to this :).
Cheers,
Danny
Compilation process in C involves four steps: pre-processing, compiling, assembling, and linking. The preprocessor tool helps in comments removal, macros expansion, file inclusion, and conditional compilation. These commands are executed in the first step of the compilation process.
Objective-C uses the runtime code compilation The main reason is that it uses the runtime code compilation, rather than the compile time. This means that when the Objective-C object calls for another object in the code, there is an extra level of indirection involved.
There are three basic steps involved in compiling a C program: preprocessing, compilation of C source code to machine code (or assembly) (also called object code), and linking of multiple object files into a single binary executable program.
You get the idea more or less correctly. A few corrections:
#include
doesn't check whether it's already included or not, but #import
does check.
.m
is not first converted to C and then to object code. It was done that way 20 years ago, but it's no longer the case. It's just directly compiled down to object code.
The linker doesn't care how the file was named. You can use different file names for .h
and .m
. You can split implementations of functions declared in a .h
file into multiple .m
files, for example.
Whether unused implementations are deleted or not depends on the compiler and the compiler options.
In any case, your conclusion is correct: you should never include/import an implementation file to another implementation file. You will run into a double-implementation error.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With