I first encountered files ended with .tc and .th in a C library (http://www.vlfeat.org/api/files.html, only .tc files are listed there. To see .th file, one has to download its source code http://www.vlfeat.org/download/vlfeat-0.9.5-bin.tar.gz. They are under vl directory.). Just wonder what do they mean and relation with normal .h and .c files ?
Thanks and regards!
They use those as a template and the files are not compiled directly, but by being #included in the corresponding .c or .h file after setting #defines that affect the final result.
One example is what happens in mathop_sse2.c. They include the same mathop_sse2.tc twice, but the first time FLT is defined as VL_TYPE_DOUBLE and the second time is VL_TYPE_FLOAT. That way they avoid duplicating the exact same code for different types.
Seems most likely these files were written using the Borland compiler.
Related
I'm in the process of learning C for a coursework assignment. One thing that confuses me is header files. I've tried to find some information regarding my question to no avail.
My question is, say I have 3 different .c files. The convention is (atleast from reading sources) - each .c file has it's own .h file, e.g. parser.c has parser.h, lexer.c has lexer.h, typechecker.c has typechecker.h (if we were making a compiler).
We then go on to add a statement:
#include "parser.h"
#include "typechecker.h"
in the lexer.c file, and do the same with the other .c files (changing the header files we include).
Instead of using that convention, is it okay to add all the prototypes for all 3 classes files into one header, say header.h, and just include that in all 3 classes? The problem with this is that the 3 classes will have prototypes of functions already included in this class, but I don't see this as a problem (I'm a beginner at C so I could be wrong).
Thanks.
what you suggest is permissible but not recommended. Having all prototypes in one header will cost you in terms of compilation and building. try to concentrate on "why header files are used?". if you get this answer you will refrain from adding everything in one header file. header files are meant for modularity to provide source files only those information which they need. Secondly in large projects you have to define "private" header files which are used internally by your code and are not visible to outer word. Ofcourse you will provide other users with header file in order to use your code.
So It is not advisable to put all prototypes even in your start of learning. As starter, make one header file per source file.
EDIT
if your header1.h has function function1(), wherever(all source files) you use function1(), you will add header1.h
I work for a group in which our test bucket has hundreds of .c source programs. The .c programs are fairly small and they all include the same 10 .h header files. These .h files are fairly large.
Each time we get a new library file to link our test programs to test, we run a script to recompile and run our test bucket against. The problem is that the compiling takes fairly long, especially if the environment is virtual.
Is there a way to compile the .h header files once, put in a separate object file and have those many .c source files link to said object file? I think this will speed up compiling time. I am willing to change/remove all the #include in the .c source programs.
Any suggestions to speeding up compile time is greatly appreciated.
Also, I should say that a script executes a makefile PER .c source test program! The makefile is not told to compile all programs in the current directory. Each test program is compiled into its own executable.
You could use precompiled header feature. See http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
You've asked further suggestions to speed up your compilation.
One way can be using ccache. Basically, ccache keeps a cache of the object files compiled so far and returns them (instead of re-compiling again over and over) when it recognises that the same source file is being compiled again.
Using it should be as simple as
Install ccache
Prefix your gcc/cc/g++ command with ccache
Rewrite your headers. Strip off all definition and leave in header. Strip off all implementation and put in new .c. Compile as library. Link with solution. Distribute library on runtime system.
If I understand correctly, the way libraries typically work is by using precompiled code in object files ( .so on Linux systems? ), while providing header files ( .h ) for use in projects.
What happens is when you compile, the #include <library.h> directive finds that header and pastes its contents in the source file being compiled. Then, once the source file is compiled, it is linked to the precompiled object file. That way, the library can be included in a huge number of projects without it needing to be compiled from source each time. The only part that must be recompiled when linking to a library is the ( relatively ) small amount of code in the headers, which essentially makes library functions and variables accessible to the source code.
All this means is that to drastically speed up compilation, your best bet is to take all of the functions out of the 10 .h files, and instead leave only the function prototypes in the headers. Once you have all of the functions in separate .c source files, you can compile them into an object file ( typically -c flag ). Then, whenever you need to compile a new program against the 10 headers you typically use, you can instead include your stripped down version of the headers, and link to the precompiled object. Since only the new code in the .c file has to be compiled, instead of all of the code in the headers, the process should be much faster.
I am studying the C language, and I saw a new extension that I had not seen before.
What do files with the extension like library.h.in mean?
Is it as the simple header with extension ".h"? What's the difference?
These files are usually the input for autoconf which will generate final .h files.
Here's an example from PCRE:
#define PCRE_MAJOR #PCRE_MAJOR#
#define PCRE_MINOR #PCRE_MINOR#
#define PCRE_PRERELEASE #PCRE_PRERELEASE#
#define PCRE_DATE #PCRE_DATE#
Autoconf will replace all variables (#…#) with the respective values and the result will be a .h file.
Typically, a .h.in file is a header template that is filled in to become the actual header by a configure script based on the outcome of several tests for features present on the target platform.
Files ending with .in are typically template files used by a program called configure that generates a new file without the extension after substituting for variable expansions. I.e., if you're looking at a source tree that has files called, e.g. Makefile.in in the tree, then ./configure will generate a usable Makefile that can be used to "make" from source.
I have two sets of header files and .c files in my project i will only ever be including one of these headers but i want the option to quickly swap the header im including. Both header files have some declarations that are exactly the same but the implementations in the .c files are different. Basically what I need is way to tell the compiler to only compile the .c file that is associated with the header im including elsewhere in my program.
You could always specify the .c or .o file that you're going to link against at compile/link time for instance
gcc -o myexe file1.c/file1.o
or
gcc -o myexe file2.c/file2.o
you could even make this a different make directive if you have a makefile if you have the same header file but 2 different implementations. I would recommend just using 1 header file and changing the underlying implementation, no point in having 2 headers with similar declarations.
If both header files are exactly the same then you don't need to maintain two header files. You can keep only one copy. Whichever code includes the header file can include this single header file only.
You can always specify which .c file you want to compile while compiling. In gcc, you can mention the C file to be compiled in the command line. In Visual Studio, you can include the correct C file.
I guess you should maintain only one header file and include that in your code. Introduce a flag to the makefile to link which implementation to be linked. You have not mentioned what are you using to build.
When Eclipse creates a new file (.c or .h file) in a C project the editor always auto creates a #define at the top of the file like this: If the file is named 'myCFile.c' there will be a #define at the start of the file like this
#ifndef MYCFILE_C_
#define MYCFILE_C_
I have seen other editors do this as well (Codewright and SlikEdit I think).
The #defines don't seem to do anything for the editor as I can just delete them without any problem, and I can't think of a reason why I would want to use them. Does anyone know why they are there?
It's to guard against multiple definitions.
Sometimes people include a whole .c file in other .c files (or even .h files), so it has the exact same purpose of preventing an include file from getting included multiple times and the compiler spitting out multiple definition errors.
It is strange, though, that it would be the default behavior of an editor to put this in anything but a .h file. This would be a rarely needed feature.
A more modern version of this is to use:
#pragma once
It is quite unusual to see this in a .c file, normally it is in the header files only.
I think it's a throwback of C include issues, where multiple copies of the source would get included - unless you are meticulous with include chains (One file includes n others).
Checking if a symbol is defined and including only if the symbol is defined - was a way out of this.