Alongside main.c file, I have following my_custom_data_structure.c file in my project. My my_custom_data_structure.c file contains a lot of variables, functions, etc.
I am using #include "my_custom_data_structure.c" directive in main.c.
Problem
I would like to import only single function called foo from my_custom_data_structure.c. I don't need all the variables and functions, which are declared in my_custom_data_structure.c file.
Any insights appreciated.
File structure
-
|- main.c
|- my_custom_data_structure.c
Content of my_custom_data_structure.c
#include <stdio.h>
int DELAY = 20;
int SPEED = 7;
char GRANULARITY_CHAR = 'g';
unsigned int RANGE = 3;
void foo(){
// TODO: In future, this function will print SPEED.
printf("foo works!");
}
/*
The rest of this file is filled by a lot
of code, which is not needed for main.c
*/
Content of main.c
#include <stdio.h>
#include "my_custom_data_structure.c"
int DELAY = 3;
int main(){
foo();
printf("Delay is %d", DELAY);
return 0;
}
UPDATED: Added working example
The usual way is to compile them separately. So you have your main.c, and your extra.c, and you should create a extra.h (and include it in main.c).
In this extra.h, put in declarations for anything that is to be exported from your extra.c file.
For example any functions that should be available to other files. All other functions should be declared/defined only in your extra.c as static, so that they are not available as symbols to be linked when main.c is compiled.
Normally, you don't include source files (.c) inside other source files (or inside headers). It's possible (and occasionally necessary), but it isn't usual.
Unless you've designed the my_custom_data_structure.c to allow you to specify which functions are to be compiled, you get everything in the file. For example, you could use:
#ifdef USE_FUNCTION1
void function1(void *, …)
{
…
}
#endif /* USE_FUNCTION1 */
around each function, and then arrange to
#define USE_FUNCTION1
before including the source, but that's not usually a good way of working. It's fiddly. You have to know which functions you use, and which other functions those need, and so on, and it is vulnerable to changes making the lists of USE_FUNCTIONn defines inaccurate. Of course, the source code might have blocks of code like:
#ifdef USE_FUNCTION1
#define USE_FUNCTION37
#define USE_FUNCTION92
#define USE_FUNCTION102
#endif /* USE_FUNCTION1 */
so that if you say you use function1(), it automatically compiles the other functions that are required, but maintaining those lists of definitions is fiddly too, even when the definitions are USE_MEANINGFUL_NAME instead of a number.
Create a header (my_customer_data_structure.h) declaring the functions and any types needed, and split the implementation into many files (mcds_part1.c, mcds_part2.c, …).
Compile the separate implementation files into a library (e.g. libmcds.a), and then link your program with the library. If it's a static library, only those functions that are used, directly or indirectly, will be included in the executable.
Related
I'm new to C programming and I just started studying functions.
Should I put each function in a .c and .h file, or can I put all of the functions and headers in one .c and .h file?
Determining where to put different parts of your code is something that comes with both your personal and the programming language experience. Considering your mention that you're currently learning about functions, let me go over a couple main factors in deciding where to put your functions.
Prototypes
When writing your code, before you can use a variable, you need to declare it first. The same goes for functions. The first, simple approach is defining a function before you use it.
int add(int a, int b) {
return a + b;
}
int main(void) {
int result = add(10, 8);
return 0;
}
Here I defined a function add() and called in the function main(). This piece of code will simply compile and run. However, what if I placed my definition of the add() function below the main() function?
int main(void) {
int result = add(10, 8);
return 0;
}
int add(int a, int b) {
return a + b;
}
This piece of code will result into a compilation error. The compiler doesn't know which add() function I'm calling in the main() function, because no add() function has been defined yet. Sometimes you can solve this problem by simply re-arranging the code. Other times that is not possible and that's why prototyping comes into play.
int add(int a, int b);
int main(void) {
int result = add(10, 8);
return 0;
}
int add(int a, int b) {
return a + b;
}
This tells the compiler there is a function add() accepting two int parameters, that will be defined later in the code. The compiler is satisfied and indeed - this piece of code compiles without an issue once again.
The #include directive
Including headers in C is a bit troublesome. It is the method of including the definitions in header files inside your .c files, and it's done in the simplest way imaginable - every #include <my_header.h> directive in your C code gets simply replaced with all contents of the my_header.h file before the compilation. For example imagine the following files:
my_header.h
// Hello, I am the my_header.h file
// I currently have no definitions
my_program.c
#include "my_header.h"
int main(void) {
// Do nothing
return 0;
}
If I compile just my_program.c, the preprocessor will examine the file before the compiler does. It will find an #include directive, look for a file named my_header.h, find it and copy its contents into the .c file simply like this:
// Hello, I am the my_header.h file
// I currently have no definitions
int main(void) {
// Do nothing
return 0;
}
Then the resulting file will be given to the compiler.
While this approach is incredibly simple and easy to implement, it makes C very prone to errors and hard to maintain, unless great care is taken. This is for example the reason include guards exist. Imagine you include two files in your main file. Now both of those two files include one, third file. After all the replacements done, you'll end up having the third file pasted twice inside your code, which will result in naming conflicts during a compilation.
This also means you technically can put any sort of code inside the header files. However, in my whole career, I was met with only one case when such code was acceptable (in a bare metal embedded system program), so I can't stress this out enough - unless you really, really know what you're doing, never put anything other than function prototypes, variable declarations, includes and macros inside a header file. Doing otherwise is the easiest way to have your code break in the most inexplicable of ways.
The conclusion
The style I've seen the most often (and also personally follow) is separating sets of functions with similar functionalities into individual .c files. This .c file contains nothing, but function definitions (i.e. the code) and a single #include directive of the header file this .c file is associated with. This keeps all the functions in a separate translation unit.
The header file with include guards (isn't needed when you don't include the file more than once anywhere, but it's a good habit to get used to) contains all the required #include directives of system libraries, other header files in your project and function prototypes of every function in the respective .c file. Whenever you then need to use those functions elsewhere, include this header file in any other header file. System libraries are generally included using <> while your own files are included using "".
As remarked by other answers, the .c file containing the main function often exists without its respective header file. All other .c files should have a header file associated. This is mostly in line with the Google's C++ Style Guide.
An example
For any smaller project, you most likely won't need more than just two files. Take these as an example:
main.h
#ifndef _MAIN_H_
#define _MAIN_H_
#include <stdio.h>
// any other includes
int add(int a, int b);
int sub(int a, int b);
int main(int argc, char *argv[]);
#endif // _MAIN_H_
main.c
#include "main.h"
int main(int argc, char *argv[])
{
int first = 10;
int second = 8;
int third, fourth;
third = add(first, second);
fourth = sub(third, first);
return 0;
}
int add(int a, int b)
{
return a + b;
}
int sub(int a, int b)
{
return a - b;
}
If you were to add more mathematical functions, say mul() and div(), it'd be appropriate to take them all out of the main.c file and create a new pair of files - something along the way of my_math.c and my_math.h, following the same rules as the rest of your project. Then, to call the mul() function in your main function, you'd need to #include my_math.h inside main.h.
A lot of this comes with the experience. Feel free to explore other styles and try out what works the best for you. The most important part in all of this is staying consistent. Pick a style and stick to it. Best of luck in your studies!
Should every function (definition) in C have its own .c file?
No. should not, but can. It's a matter of coding-style, but it's not the preferred way to do so and unusual. It increases compilation and linking time.
Or can I put all the function (definitions) of my program in one .c file?
Yes, you can. Also again, matter of one's own coding-style.
If you got a lot or several functions in your code, you can also group the function definitions into own .c files and then link the files when invoking the compiler.
This way you keep clarity.
One way is also to keep all function definitions in a separate .c file, apart from main.c, which contains the main function.
Should I put each function in a .c and .h file?
Function definitions can't be placed inside of .h files.
.h consist only of function and other variable declarations, as well as macro definitions.
Function definitions need to be placed in .c files.
If you mean to place each function definition into an own .c file and each function declaration in an own .h, that definitely does not need to be either.
It even would confuse you all the way up.
You actually can do so, but it is definitely not recommended.
Or can I put all of the functions and headers in one .c and .h file ?
Again here you can't put function definitions in an .h file.
But you can pack all function definitions in one .c file and all function declarations in one .h file.
No! There is no need to do it at all. That would be affect your performance really badly.
Usually we only tend to create new files .h to store functions/methods that we want to use repeatedly in other projects or programs I guess.
Your program should be as follows:
Let's call this prog1.c
#include <only libs that you need>
void functionA (parameterType parameter){
//Whatever your function needs to do
}
int main(){
//this is your main function and where the program will start working.
functionA(parameters) /*Here is how you call functionA if it's void giving it's needed parameters.*/
}
Later on, with more knowledge you'll learn when you need to store or not the functions in others files to learn and keep it organized. There's no need for that now. You should focus the most on learning how they work and communicate with each other.
If you need to use functionA in other file, well then you will just need to include that .c file, like this:
In prog2.c you start it by calling out
#include "prog1.c"
I've inherited some code* which declares and defines a struct in a header file (a_A.h). This struct is in the top file of an include hierarchy tree which symbolically looks like:
file: t_T.h (#includes "c_C.h") //defines a struct
file: c_C.h (#includes "h_H.h")
file: h_H.h (#includes "a_C.h")
file: a_C.h (#includes <stdio.h>)
Each header has the appropriate header guards and appear to be non-recursive when looked at as a flat collection of files. However, files c_C.h and a_C.h reside in the same library. While h_H.h resides in a different library. From a library perspective this symbolically appears as:
t_T.h (includes a file from Lib_C)
Lib_C: (includes a file from Lib_H)
Lib_H (includes a file from Lib_C)
which is recursive and is the likely cause of redefinition problems when I compile the code (the linker complains that the struct in file a_C.h is redefined).
1) Did I correctly identify the issue?
2) If so, why? I am guessing that linked objects in a library appear flat to the linker (i.e. they've lost their hierarchy context). And if guessed somewhat correctly then:
3) Should I consider header guards to be limited to the scope of their respective library?
Below is the error statement from the problems window:
symbol "ov5642_1280x960_RAW" redefined: first defined in "./TakePhoto.obj"; redefined in "./ArduCam/ov5642_Config.obj"
Header in ./TakePhoto:
#ifndef TAKEPHOTO_H
#define TAKEPHOTO_H
#include "ov5642_Config.h"
#include "HAL_ArduCAM.h"
...
#endif /* TAKEPHOTO_H_ */
Header in ./ArduCAM/ov5642_Config.h:
#ifndef ARDUCAM_OV5642_CONFIG_H_
#define ARDUCAM_OV5642_CONFIG_H_
#include "HAL_ArduCAM.h"
#include "ov5642_Sensor_Values.h"
....
#endif /* ARDUCAM_OV5642_CONFIG_H_ */
Header in HAL_ArduCAM
#ifndef HAL_ArduCAM_h
#define HAL_ArduCAM_h
#include <stdint.h>
#include "driverlib.h"
....
#endif /* HAL_ArduCAM_h */
ov5642_Sensor_Values.h has the following
#ifndef ARDUCAM_OV5642_SENSOR_VALUES_H_
#define ARDUCAM_OV5642_SENSOR_VALUES_H_
#include <stdint.h>
const struct sensor_reg ov5642_1280x960_RAW[] =
{
{0x3103,0x93},
{0x3008,0x02},
{0x3017,0x7f},
.....
#endif /* ARDUCAM_OV5642_SENSOR_VALUES_H_ */
It seems that the contents of OV5642_Sensor_Values is copied twice, once for TakePhoto and once again for ovV5642_Config despite their header guards. My original thought was that there was a recursive dependencies but didn't find it.
Ok, I've made an example pasted below. There are five files in this example, three files (bar.h, foo.h, foo.c reside in a library), the other two files (foo1.h, foo1.c) do not. Notice that foo.h includes bar.h and that foo1 includes both foo.h and bar.h.
I am conjecturing that the guard headers of bar.h are not preserved when the pre-processor copies into foo.h. Thus when foo1 includes bar.h and foo.h the symbol redefinition arises. So to answer my own question, no, it is not a library issue. Not preserving the header guard seems the likely cause of my problem.
They are pasted below.
/*
* bar.h
*
*/
#ifndef ARDUCAM_BAR_H_
#define ARDUCAM_BAR_H_
#include <stdint.h>
typedef struct regStruct {
uint16_t reg;
uint8_t val;
} regStruct;
const struct regStruct regArray[] =
{
{0x3103,0x03},
{0x3104,0x03},
{0x3008,0x82},
{0xffff,0xff},
};
const struct regStruct tinyArray[] =
{
{0x3106,0x03},
{0x3003,0x82},
{0xffff,0xff},
};
#endif /* ARDUCAM_BAR_H_ */
/*
* foo.h
*
*
*/
#ifndef ARDUCAM_FOO_H_
#define ARDUCAM_FOO_H_
#include <stdint.h>
#include <stdio.h>
#include "bar.h" //including this file causes redefinition
typedef struct Init_Parameters {
//! Select sensor resolution
//! options.
//! \n Valid values are:
//! - \b big
//! - \b small
//! - \b tiny
uint8_t size;
} Init_Parameters;
uint8_t Sensor_Init(Init_Parameters *param);
typedef enum {
small=0,
big,
tiny
} select_size;
#endif /* ARDUCAM_FOO_H_ */
/*
* foo.c
*
*
*/
#include "foo.h"
uint8_t Sensor_Init(Init_Parameters *param)
{
switch(param->size)
{
case big:
break;
case small:
break;
case tiny:
break;
}
return 0x01;
}
/*
* foo1.h
*
* Created on: Feb 28, 2019
* Author: jnadi
*/
#ifndef FOO1_H_
#define FOO1_H_
#include "foo.h"
#include "bar.h"
#endif /* FOO1_H_ */
/*
* foo1.c
*
* Created on: Feb 28, 2019
* Author: jnadi
*/
#include "foo1.h"
void Camera_Init(){
Init_Parameters setParams; //create instance
setParams.size=big;
Sensor_Init(&setParams);
}
The physical locations of header files affect C source compilation only via the include-file search path. Headers have to be in one of the directories that are searched, and if there is more than one with the same name, then the search path order determines which is used. The association, if any, between a given header and a library is not known to the compiler, and it does not affect compilation, unless indirectly via the search path.
Your claim that
the linker complains that the struct in file a_C.h is redefined
(emphasis added) makes sense only if by "the struct" you mean an object of a structure type. The linker may complain if a variable with external linkage is defined in more than one translation unit, which will likely happen if a header contains a definition of that variable (as opposed to merely a declaration).
If instead the issue is that the structure type is redefined, then that would be diagnosed by the compiler, not the linker, and it would tend to contradict your conclusion that
Each header has the appropriate header guards
. Proper header guards are exactly what would prevent such a type redefinition issue.
1) Did I correctly identify the issue?
Not with any specificity, for sure. That there are header dependencies in both directions between headers associated with different libraries reflects poor design, but it would not inherently cause compilation or linking to fail.
2) If so [...]
N/A
3) Should I consider header guards to be limited to the scope of their
respective library?
No. Header guards are relevant at the compilation stage only, and C compilation knows nothing about libraries. All header files processed by the compiler in the course of translating a single translation unit are on equal footing. In fact, the main risk in this area is in the opposite direction: a collision of header guards.
That answers the question as posed. As for what the true nature of your build issue may be, you have not given us enough information to do more than speculate. My own speculations are already conveyed above.
Using the five files posted above and commenting out an #includes bar.h in foo.h, I believe I found the answer to my problem.
The simple answer is that header guards are not preserved once it is included into the header of another file.
When bar.h is included into another header file, its header guards are superseded by the header guards of its new host (foo.h). Thus symbol redefinition issues arise when foo1.h includes both bar.h and foo.h
Header guards only prevent a .h file from including its contents twice or more within one top-level translation unit. They are to deal with cases like this, where two or more headers need to include the same set of common definitions:
// A.h
struct A { int x, y, z; };
// B.h
#include "A.h"
struct B { struct A aye; float f, g; };
// C.h
#include "A.h"
struct C { struct A aye; long l, m; };
// main.c
#include "B.h"
#include "C.h" // error, redefinition of struct A
But each translation unit starts out with a clean macro environment, so if you include a header file in two different top-level translation units, that header's declarations are made visible (once) to each. And that's what you want. (Think about standard library headers. You wouldn't want stdio.h not to declare printf in bar.c just because there existed foo.c in the same project that also included stdio.h.)
Now, your problem is that ov5642_Sensor_Values.h defines a data object (not a type), ov5642_1280x960_RAW, and this header is included into two different top-level translation units (.c source files). Each translation unit produces an object file containing a definition of ov5642_1280x960_RAW, and you get a multiple definition error from the linker when you try to combine them.
The bug causing this problem is not that ov5642_Sensor_Values.h's header guards are ineffective. The bug is that ov5642_Sensor_Values.h should not be making any global definitions. Header files should only declare things (with rare exceptions that you shouldn't worry about until you encounter them).
To fix the bug, change ov5642_Sensor_Values.h to declare ov5642_1280x960_RAW but not define it, like this:
#ifndef ARDUCAM_OV5642_SENSOR_VALUES_H_
#define ARDUCAM_OV5642_SENSOR_VALUES_H_
#include <stdint.h>
#include "sensor_reg.h"
extern const struct sensor_reg ov5642_1280x960_RAW[];
#endif
and create a new file named ov5642_Sensor_Values.c that contains the initialized definition:
#include "ov5642_Sensor_Values.h"
extern const struct sensor_reg ov5642_1280x960_RAW[] =
{
{0x3103,0x93},
{0x3008,0x02},
{0x3017,0x7f},
.....
};
and add that file to your link.
thank you everyone especially John, Zwoi. I was up against a deadline (this was inherited code) but was able to calm myself down enough to figure out what John was saying. I moved the struct definition into a c file and used an extern pointer in the header which is similar to zwoi's declaration. I am also relieved that what I did matched zwoi's example (thank you so much!).
extern const struct sensor_reg * ov5642_1280x960_RAW;
I'm wondering whether a C file can be both included in another script (through a header file), and also run independently (by having its own main function). That is, the C file can be included to provide its functions to another C script, but can also itself be directly ran to provide some alternate functionality.
For example, a python script can do this;
def functionsToBeImported():
# code to be run by an importing script
pass
if __name__ == '__main__':
# code to be run by this script independently
pass
This code can be imported (import ABOVESCRIPT) by another python file to give access to functionsToBeImported, or independently run (python ABOVESCRIPT.py) to execute the code within the if block.
I've attempted to do this in C via myScript.c:
#include "myScript.h"
void functionsToBeImported() {
}
int main (int narg, char* varg[]) {
}
myScript.h:
#ifndef MY_SCRIPT_H_
#define MY_SCRIPT_H_
void functionsToBeImported();
#endif // MY_SCRIPT_H_
but trying to include this in anotherScript.c:
#include "myScript.h"
int main (int narg, char* varg[]) {
functionsToBeImported();
}
and trying to compile via
gcc -std=c99 -c myScript.c
gcc -std=c99 -c anotherScript.c
gcc -std=c99 -o anotherScript anotherScript.o myScript.o -lm
gives be a compilation error
duplicate symbol _main in:
myScript.o
anotherScript.o
How can I achieve this 'double-use' script?
You cannot link both anotherScript.o and myScript.o, but you could do something like this:
#define main ignored_main
// Include myScript.c, not myScript.h
#include "myScript.c"
#undef main
int main (int narg, char* varg[]) {
functionsToBeImported();
}
I have actually seen things like this in code very widely used in production, although I cannot recommend this style (but it is sometimes a tempting shortcut).
Another option is to include the main function only if a preprocessor macro is defined, like this (in myScript.c):
#include "myScript.h"
void functionsToBeImported() {
}
#ifdef USE_MAIN
int main (int narg, char* varg[]) {
}
#endif // USE_MAIN
This is similar in spirit to the Python approach. But again, you will have to compile this file twice into separate object files.
Note: C files are not scripts.
You cannot have two main functions, as C is a procedural language, meaning you must do one thing at a time (unless you are multithreading, in which case you would still only have one main function).
HOWEVER, there is something quite close to replicating what you want. What you can do is first, write the main method only in the first included file. In the main file, set the atexit() function from the C stdlib.h file (which calls another function at the end of main) to a main2() function (make sure that there is a prototype of each main#() function in the first header as well, and implement all of the functions eventually). Define a macro called MAIN_ONE in the function with the original main. In each consecutively included file, implement the next main and create a macro so that checks to see if the function was implemented can be made. However, the natural, and most efficient way to make a program in C is to just have one main function.
Example:
//In first included file
#include //Some IDEs automaticaly include this. This must be included since it is where the atexit() function resides
#define MAIN_ONE
void main2(); //For the moment, this is only a prototype.
void main3();
//etc. Until you have created the maximum number of main functions that you can have
int main() {
//do something
atexit(main2); // This will execute the function main1() once main returns
//All "fake" mains must be void, because atexit() can only receive void functions
}
//In second included file
#if defined(MAIN_THREE) //start from the maximum number of main functions possible
#define MAIN_THREE //The define is for preprocessor-checking purposes
void main4() {
atexit(main5);
}
#elif defined(MAIN_TWO) //start from the maximum number of main functions possible
#define MAIN_TWO
void main3() {
atexit(main5);
}
//Keep repeating until you reach #ifdef(MAIN_ONE)
#endif
//At the bottom of the main C file
//This is done in order to make sure that all functions have actually been created and reside in memory so that an error does not occur
//(all unused functions are initialized with an empty function here)
#if defined(MAIN_THREE) //start from the maximum number of main functions possible
//Do nothing because if MAIN_THREE is defined when main4(), the last main in my example has already been implemented.
//Therefore, no more functions need to be created
#elif defined(MAIN_TWO) //start from the maximum number of main functions possible
#define MAIN_TWO //Since more mains after main2 can be present, another macro for future checks needs to be defined
void main3() {
}
//Keep repeating until you reach #ifdef(MAIN_ONE)
#endif
What are advantages and disadvantages of both approaches?
Source vs. header implementation
Function definition inside source file
Header file sourcefunction.h contains declaration only.
#ifndef SOURCEFUNCTION_H
#define SOURCEFUNCTION_H
void sourcefunction(void);
#endif // SOURCEFUNCTION_H
Source file sourcefunction.c contains definition
#include "sourcefunction.h"
#include <stdio.h>
void sourcefunction(void) { printf(" My body is in a source file\n"); }
Function definition inside header file
Header file headerfunction.h contains definition which is the declaration at the same time.
#ifndef HEADERFUNCTION_H
#define HEADERFUNCTION_H
#include <stdio.h>
void headerfunction(void) { printf(" My body is in a header file\n"); }
#endif // HEADERFUNCTION_H
No source file is needed.
Consumer
File main.c
#include "sourcefunction.h"
#include "headerfunction.h"
int main(void) {
sourcefunction();
headerfunction();
return 0;
}
Why compile many source files?
We have to compile all source files and remember about them during linking.
gcc -c sourcefunction.c
gcc -c main.c
gcc main.o sourcefunction.o
Make can handle file managing but why even bother?
Is separation of interface and implementation always an issue?
It is obvious reason for big projects and teamwork. The designer specifies the interface. The programmers implement functionality.
What about smaller projects and non-formal approach?
Is removing definition from header files always preventing from linker errors?
Let's assume my program is using another module that defines the function with the same name sourcefunction().
#include "sourcefunction.h"
#include "sourcefunction1.h"
#include "headerfunction.h"
int main(void) {
headerfunction();
sourcefunction();
return 0;
}
Different function interface
File sourcefunction1.h
#ifndef SOURCEFUNCTION1_H
#define SOURCEFUNCTION1_H
int sourcefunction(void);
#endif // SOURCEFUNCTION1_H
File sourcefunction1.c
#include "sourcefunction1.h"
#include <stdio.h>
int sourcefunction(void) { int a = 5; return a; }
By compiling main.c, I get a nice compiler error
sourcefunction1.h:4:5: error: conflicting types for 'sourcefunction'
showing me the location of error.
Same function interface
File sourcefunction1.h
#ifndef SOURCEFUNCTION1_H
#define SOURCEFUNCTION1_H
void sourcefunction(void);
#endif // SOURCEFUNCTION1_H
File sourcefunction1.c
#include "sourcefunction1.h"
#include <stdio.h>
void sourcefunction(void) { int a = 5; printf("%d",a); }
Compiler does not mind multiple declarations. I get ugly linker error.
Can header implementation serve as library?
jschultz410 says
If you are writing a library and all your function definitions are in headers, then other people who do segment their development into multiple translation units will get multiple definitions of your functions if they are needed in multiple translation units
Lets' have
File consumer1.c
#include "headerfunction.h"
void consume1(void) { headerfunction(); }
File consumer2.c
#include "headerfunction.h"
void consume2(void) { headerfunction(); headerfunction();}
File twoConsumers.c
extern void consume1(void);
extern void consume2(void);
int main(void) {
consume1();
consume2();
return 0;
}
Let's compile sources.
gcc -c consumer1.c
gcc -c consumer2.c
gcc -c twoConsumers.c
So far, so good. Now, linking.
gcc consumer1.o consumer2.o twoConsumers.o
Linker error: multiple definition of 'headerfunction', of course.
But I can make my library function static.
File headerfunction.h, afterwards.
#ifndef HEADERFUNCTION_H
#define HEADERFUNCTION_H
#include <stdio.h>
static void headerfunction(void) { printf(" My body is in a header file\n"); }
#endif // HEADERFUNCTION_H
It hides the definition from other translation units.
I shouldn't answer this, but I will.
This can create duplicate definitions unless you really only have a single .c file in your project (unwise). Even the header guards won't prevent files the headers from being included multiple times if those multiple times are with different .c files. When the .obj files are linked together, there will be conflicts.
If only the function declaration and not definition is in the header, then only changes to the interface (the function name, parameters or return type) require recompiling dependencies. However, if the entire definition is in the header, then any change to the function requires recompiling all .c and .h files that depend on it, which, in a larger project, can create a lot of unnecessary recompiling.
It's not the convention. Libraries will not use this convention, so you'll be stuck dealing with their header file structure. Other developers will not use this convention, so you can create confusion or annoyance there.
I have been reading about C for a while now and decided lets write a little add program, nothing fancy at all. My understanding of C headers is that they are "interfaces" (such as like java and other languages) but where you can also define variable that either have set values or not..
So I wrote this:
#include <stdio.h>
#include <stdlib.h>
#include "sample.h"
int main(int argc, char** argv) {
printf("hello World\n");
add(12, 18);
return (EXIT_SUCCESS);
}
int add(int a, int b){
int value = a+b;
printf("value = %d\n", value);
return 0;
}
It has a header file that looks like such:
#ifndef SAMPLE_H_GUARD
#define SAMPLE_H_GUARD
int add(int a, int b);
#endif
I thought header files, and this is where I am lost on their definition, was suppose to define the use of add, so all I would have to do is call add - From my understanding, I define the rules of add and then implement the functionality of add....
Also, A lot of the material I have read shows one header file for multiple C files. where as a lot of projects today have one header per one c, meaning Sample.h belongs to Sample.c and nothing else.
Can some one shed some light on this?
Could I have done this like so:
main.c
#include <stdio.h>
#include <stdlib.h>
#include "sample.h"
int main(int argc, char** argv) {
printf("hello World\n");
add(12, 18);
return (EXIT_SUCCESS);
}
add.c
#include <stdio.h>
#include <stdlib.h>
#include "sample.h"
int add(int a, int b){
int value = a+b;
printf("value = %d\n", value);
return 0;
}
sample.h
#ifndef SAMPLE_H_GUARD
#define SAMPLE_H_GUARD
int add(int a, int b);
#endif
I believe in the book I was reading: C Programming Language they had a calculator example split up like this, my question is how does C know where add is defined? It knows the rules for it based on the header file, i think, but not where the actual implementation is ....
There example where they split of the files like such doe not have something like #include "add.c" all they do is include the header file in the files that either implement or use this functionality.
Note: obviously the calculator example and my example are going to be different but fundamentally the same - for those who have the book. I am just lost on how to use header files effectively and efficiently.
A header file in C would declare the function add for those modules that need it, but not define the function. The function is still to be defined in its own module (e.g., in your case, add.c).
So in general, to make a function foo available to several modules, you would normally:
Choose a header file (maybe it's own if there are other associated
defines, etc) to declare foo. For example, perhaps foo.h would
have void foo(...);
In some module, perhaps foo.c, you would define the complete
function foo.
In any module that wants to call foo, you would #include "foo.h"
(or whatever header you used) and call the function.
When you compile/link the code, you would make sure all modules,
including foo.o or whatever module has foo defined in it, were
present.
A declaration, given in the header file, provides (of course) the function name, the function return type as well as listing all the parameters and their types. This is all the compiler needs to know to figure out how to call the function from the calling module. At link time, addresses are all resolved so that the modules then know exactly where the function is in its own particular module.
My understanding of C headers is that they are "interfaces" (such as
like java and other languages) but where you can also define variable
that either have set values or not..
This is not correct. You cannot "define" variables - well, you can but that will cause multiple definitions error while compiling code if you include header more than once.
Could I have done this like so:
Regarding your code - both variants are correct. C language uses headers to read declarations and hence headers are optional as well. You can have your code split into as many as you want .h and .c files. Compiler will create an object file for each .c file. All .h files included in a c file are basically embedded in that C file "before compilation" i.e. in preprocessing phase. Linker then comes in picture which combines objects to produce the executable.
Please don't hesitate if something is not clear in my answer.