Quote:
|
Originally Posted by warrener
It's interesting to see I don't have to include code.c in my code, why is that?
|
What you are doing defies convention, & here is why:
- Typically, only header files are included because by convention, they contain only declarations, not definitions (which requires space to be allocated...). Most header files distributed with compilers are bracketed with the following convention:
#if !defined(HEADERFILENAME_H)
#define HEADERFILENAME_H
//...
#endif
...which prevents header files from being included more than once (This can be a problem if header file A includes header file B which includes header file A...). Thi s type of circular inclusion can be a common problem in large projects. - By including source code, you may be causing the situation where global variable definitions are being defined in multiple files. The linker should catch duplicate definitions which are global, however there is the pathology where an inclusion may end up in a block which is declared static (If you are unfamiliar with static definitions, look it up...). Because the linker does not see static definitions, you would in effect be creating multiple variables with the same name but potentially different scopes. In a huge project consisting of hundreds of thousands lines of code, this can be very difficult to isolate. Note: because the compiler & linker cannot catch such edge cases, the convention has been established to prevent the problem. You can ask why not change the language definition. The answer is that there may be situations where this is warranted. The language is flexible enough to allow clever coding, but people can also shoot themselves in the foot if they are unaware of the consequences.
- With regards to the following:
Code:
$ gcc -O2 -c code.c
In this case, gcc is being called to act as a compiler creating the object file transformation of code.c.
However, in the case of:
Code:
gcc -O2 -o prog code.o test.c
Here, gcc is being told to link code.o with the object file created from compiling test.c into the resulting executable binary. Note that linkers can be given multiple object files when contain code for functions with the same name. Typically, the linker will simply use the first object file or library which contains the symbols which it is attempting to find. In this case, function sum() appears in both object files, but function main() only appears in test.o. Because of this, I suspect that the linker simply uses test.o to create the resulting binary. The point here is that gcc itself is not simply a compiler. It is an umbrella application which calls the underlying compiler & linker as instructed. - Finally, for your question asking why code.c does not have to be explicitly specified when calling gcc. Because you have included code.c in a non-standard way, it has already been incorporated into the code.
In summary, the tools are flexible, & strange things can be done if necessary. What you have specified is non-standard. The tools allow it, but collateral conventions growing up around C/C++ frown upon what you have done. What you should take away from this discussion is:
- It is not wise to include code which contains memory allocations.
- To a lesser degree, it is questionable to include function definitions within header files, but there a number of cases where this is warranted. inline functions & member functions are examples.
In the end, you have to be able to justify the decisions made.
10-Jun-2008, 21:29
Accepted for Ph.D. program by crystalattice
Similar Threads
