Difference between source files, header files, resource files, and external dependenc

Started by
3 comments, last by Oluseyi 19 years, 1 month ago
I am using Visual C++ 6.0 and was wondering what the difference between "Source Files," "Header Files," "Resource Files," and "External Dependencies" was. I had assumed it was just for personal organization and had not really been paying attention to it. I had my main program in "Source Files" and eveything else in "Header Files." But now I am getting some strange behavior that makes me think I am misusing this. Specifically, I made a file "global_variables.h" and declaired a couple of extern variables in it. (Yes, I know... but I have a couple of variables that are accessed throughout the whole program and this seems far more elegant to me than a bunch of functions to access and change them across files.) Anyway, when I #include "global_variables" in another (header) file, it does not seem to be able to properly find the variables. This seemd to be a problem with linking the files together, which made me think of my careless/ignorant treatment of the file types. Is this likly my problem or should I be looking at something else? Thanks.
Advertisement
Header files

Files with a .h, .hpp or .hxx extension, containing entity declarations and/or definitions that need to be visible to multiple translation units (see below). Some people additionally include files without any extension, or files with arbitrary extensions such as .inc, but your development environment will not recognize these as header files by default.


Source files

Each file with the extension .c, .cpp or .cxx defines a translation unit. The C and C++ compilers only compile a single file at a time. Source files may include header files, which are substituted in place for the #include statement and other directives by the preprocessor, resulting in a single "file" which is then fed to the compiler. This file must contain all type and all object declarations that are referenced, which is the meaning of the undeclared reference compiler error. Note that it only requires complete declarations to succeed; definitions are handled at a later stage in the build process.

The output of the compiler is an object file, .obj extension on Windows/MSVC, .o on Unix and GCC. This code is combined into a static library or binary executable (dynamic library or executable module) by the linker, which must resolve all external references to succeed. These external references include type and object declarations: matching definitions must be found.

In combining object code to yield a binary executable, only code that is actually invoked in the binary is included from object files or static libraries. This process of determination and inclusion is called relocation.


Resource files

Resource files are platform specific. In the case of Microsoft Windows and Microsoft Visual Studio, they define non-code resources such as cursors, icons, bitmap images, string tables and so forth that can be included in the output binary executable. A feature of Windows PE executables is that they may contain these resources within themselves in a special data segment, which can simplify deployment and/or access.

A resource script, extension .rc, declares the type, name and location (filename) of the resources to include. An optional resource header provides a mnemonic mapping of the resource name to numeric identifiers for use within your program header and source files. The resource compiler, RC.exe, is run to build a resource file from resource script and physical resources (bitmap files, icon files, etc). This resource file has the extension .res.

Finally, this resource file is supplied to the linker along with the object files, and is included in the output binary executable. Resource files can not be included in a static library.



That's a reasonably complete, yet concise, overview of the Windows application build process for C and C++. It should be clear that the C and C++ compile process is slow, as all the header files have to be processed for each source file that includes them - and they may include each other, necessitating inclusion guards to prevent redefinition errors. This is why incremental linkers have been developed, which can detect how much of the source material comprising the output binary has changed and what they need to re-link. This is also why pre-compiled headers which build nultiple source files that are relatively stable compared to the rest of the project into an intermediate object file have been developed, and why you should learn to use them.


Happy hacking.
So you are saying that only source files or other header files should #include header files? And that header files should never #include source files. And finally that source files should not #include other source files?
Or put mroe simply:

source #including header - yes
source #including source - no
header #including header - yes
header #including source - no

Is that correct? Thanks.
Quote:Original post by Quasius
So you are saying that only source files or other header files should #include header files? And that header files should never #include source files. And finally that source files should not #include other source files?
Or put mroe simply:

source #including header - yes
source #including source - no
header #including header - yes
header #including source - no

Is that correct? Thanks.

As a general rule, that works. It's not foolproof, though. In particular, you have to include the source to templated functions.

Check out this article. It should help you with your file problems.

CM
Quote:Original post by Quasius
source #including header - yes
source #including source - no
header #including header - yes
header #including source - no

Is that correct? Thanks.
Correct.

People sometimes like to say that there's an exception for templates. There isn't. Templates go in header files, simply because the problem of correctly exporting them to source files given future instantiation by any data type is extremely thorny (this is why Comeau is the only C++ compiler to support export for templates, and I have no feedback on how well it works and what the caveats are).

Do not put templates in source files. If you put it in a source file that is part of your project, the compiler will attempt to compile the template source, as well as all the source files that include the header that includes the template source. Boom! Redefinition errors.

This topic is closed to new replies.

Advertisement