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
Related
In what situations we need to use .h file and when to use the .c file in C.
Are they two alternatives for a same purpose?.
Please explain.
Never include .c files
If you include something, it should be a .h file.
Code goes into code files, .c.
Headers, .h files, contain only what can be compiled more than once, i.e. declarations, macro definitions, more includes.
If necessary, headers use reinclusion guards.
Whenever you feel tempted to include a .c file, you instead want to add it to your project so that it gets processed during building, i.e. gets compiled by its own and in a further build step gets linked into the created binary.
Say I am writing a small libary in C, with most of the source code in two folders src/A and src/B, and where the header file src/A/a.h needs to include src/B/b.h. When writing code for a non-library project, I usually write
#include "B/b.h"
in a.h and use the -Isrc flag to tell the compiler where to look for header files.
Now suppose that my library is installed locally at ~/mylib and that I want to use functions from a.h from a different project. Simply including that file using
#include "~/mylib/src/A/a.h"
would not work, because ~/mylib/src/B/b.h might not be part in the search path. My question is about the canonical way to solve this issue. It's probably quite basic, but I haven't done any advanced programming in C and have been unsuccessful in my attemps to find a solution online.
Possible solutions I thought of are the following:
Add ~/mylib to the search path, but that might lead to problems if the library and client projects have header files with the same name (say src/helpers.h). Is it possible to include one header file without cluttering the search space with files I won't need?
Use relative paths in the library header files, but that doesn't feel very robust.
Thank you.
The normal approach is to have a separate directory specifically for the headers which form the public interface of your library. Usually this directory would be called 'include'.
You would then place the public headers for your library under a library-specific directory in there, i.e. "mylib/include/mylib/b.h". This extra 'mylib' directory prevents clashes if you're using some other library that also has a "b.h". You can also, if you wish, keep other private headers, which do not form the public interface of your library, under the 'src' directory instead, to stop them being exposed to users of the library.
This means a user of the library can then use "-I mylib/include" to include this directory, and include the individual files with, for example, "#include "mylib/b.h".
Why aren't you using the standard implementation? Break out into header and source files into their own directories. Add #define headers to avoid multiple includes or namespace corruption.
Here is your directory structure:
~/mylib/headers/a.h
b.h
~/mylib/src/a.c
b.c
Now a.h will have at the very top of the file...
#ifndef __A_H__
#define __A_H__
// code
#include "~/mylib/headers/b.h"
// end of file
#endif
Now b.h will have at the very top of the file...
#ifndef __B_H__
#define __B_H__
// code
// end of file
#endif
Then just compile. gcc -I~/mylib/headers
If you have 2 helpers.h just change the #define __HELPERS_H__ in one of the files to something else like #define __HELPERS2_H__
Going over our course material, I noticed that when we #include standard libraries (for example #include <stdio.h>), these #includes appear in the .c file and not in the header file. The #includes that appear in the header file are those that are for local header files, #include "anotherheader.h".
Why is that? It'd make more sense to me that all #include declarations will appear in the header file, and all the .c files will derive them from there.
Whether sources files include standard headers directly or via other included files is a matter of local coding conventions.
It is considered good style to follow these conventions:
include only the necessary headers ;
include standard headers before any other include files and local declarations ;
make every source file compilable as a separate entity, including project header files. This means you should include the standard headers needed for the types used in local header files at the top of these.
protect the definitions in a header file with a header guard: #ifndef SOME_SYMBOL / #endif.
It is good practice to include only what is really necessary in the header file to avoid circular dependencies and to allow for shorter build times.
It's all in the title; super-simple I reckon, but it's so hard to search for syntactical things anywhere.
These are two library files that I'm copying from CS50.net, and I'm wondering why they have two different extensions.
.c : c file (where the real action is, in general)
.h : header file (to be included with a preprocessor #include directive). Contains stuff that is normally deemed to be shared with other parts of your code, like function prototypes, #define'd stuff, extern declaration for global variables (oh, the horror) and the like.
Technically, you could put everything in a single file. A whole C program. million of lines. But we humans tend to organize things. So you create different C files, each one containing particular functions. That's all nice and clean. Then suddenly you realize that a declaration you have into a given C file should exist also in another C file. So you would duplicate them. The best is therefore to extract the declaration and put it into a common file, which is the .h
For example, in the cs50.h you find what are called "forward declarations" of your functions.
A forward declaration is a quick way to tell the compiler how a function should be called (e.g. what input params) and what it returns, so it can perform proper checking (for example if you call a function with the wrong number of parameters, it will complain).
Another example. Suppose you write a .c file containing a function performing regular expression matching. You want your function to accept the regular expression, the string to match, and a parameter that tells if the comparison has to be case insensitive.
in the .c you will therefore put
bool matches(string regexp, string s, int flags) { the code }
Now, assume you want to pass the following flags:
0: if the search is case sensitive
1: if the search is case insensitive
And you want to keep yourself open to new flags, so you did not put a boolean.
playing with numbers is hard, so you define useful names for these flags
#define MATCH_CASE_SENSITIVE 0
#define MATCH_CASE_INSENSITIVE 1
This info goes into the .h, because if any program wants to use these labels, it has no way of knowing them unless you include the info. Of course you can put them in the .c, but then you would have to include the .c code (whole!) which is a waste of time and a source of trouble.
Of course, there is nothing that says the extension of a header file must be .h and the extension of a C source file must be .c. These are useful conventions.
E:\Temp> type my.interface
#ifndef MY_INTERFACE_INCLUDED
#define MYBUFFERSIZE 8
#define MY_INTERFACE_INCLUDED
#endif
E:\Temp> type my.source
#include <stdio.h>
#include "my.interface"
int main(void) {
char x[MYBUFFERSIZE] = {0};
x[0] = 'a';
puts(x);
return 0;
}
E:\Temp> gcc -x c my.source -o my.exe
E:\Temp> my
a
They're not really library files. They're just source files. Like Stefano said, the .c file is the C source file which actually uses/defines the actual source of what it merely outlined in the .h file, the header file. The header file usually outlines all of the function prototypes and structures that will be used in the actual source file. Think of it like a reference/appendix. This is evident upon looking at the header file, as you will see :) So then when you want to use something that was written in these source files, you #include the header file, which contains the information that the compiler will need to know.
The .c is the source file and .h is the header file.
The .c files are source files which will be compiled. The .h files are used to expose the API of a program to either other part of that program or other program is you are creating a library.
For example, the program PizzaDelivery could have 1 .c file with the main program, and 1 .c file with utility functions. Now, for the main part of the program to be able to use the utility functions, you need to expose the API, via function prototype, into a .h file, this .h file being included by the main .c file.
.c : 'C' source code
.h : Header file
Usually, the .c files contain the implementation, and .h files contain the "interface" of an implementation.
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.