I have a C file with all static functions, related to one and same sub-task.
Some of the functions are quite long - 20-30 lines.
I want to include it in another C file.
What must be the file extension (in order things to considered professional). Shall I do it as H file?
20-30 lines isn't long. 200-300 lines is getting long but still doesn't warrant a separate file.
Most projects would be unmanageable if 20 line functions had their own file.
Just put the functions in the .c file they're used in and declare them static.
I don't know what build tool you're using but traditional 'make' might get confused by .c unless you introduce further rules and discipline.
If you do put them in another file give it the .inc suffix as others suggest.
I have generally only seen people do this when the .inc is maintained by an external tool.
If you really need to share the same static methods across multiple c files (for compiler optimization?), you should place them in a .c-file and not in a .h file.
If you don't need to make those methods static, you should really place them in a single .c module which is liked to the binary and only share the definitions across the modules using them.
Example
If you really have to share the static functions and you have a really good reason
static_functions.c (I'd name it static_functions.inc.c, but that's personal flavour)
static int max(int a, int b) {
if (a > b)
return a;
return b;
}
module-x.c for some x
#include "static_functions.c"
int use_max() {
return max(1,2);
}
Compile module-x.c only.
If you don't really need static versions
internal_functions.h
#ifndef internal_functions_h
#define internal_functions_h
int max(int a, int b);
#endif
internal_functions.c
#include "internal_functions.h"
int max(int a, int b) {
if (a > b)
return a;
return b;
}
module-x.c for some x
#include "internal_functions.h"
int use_max() {
return max(1,2);
}
And then compile and link together internal_functions.c and module-x.c.
To have the definitions local only, you don't need to use or ship your internal_functions.h elsewhere.
include C file inside another
No, not the way. Conventionally,
.c [source files] are meant to be compiled and linked together
.h [Header files] are there to be included.
C file with all static methods [] Shall I do it as H file?
No. Ideally header files [.h] are not supposed to contain any definition. There should be declarations only. Otherwise, if a header file .h contains definitions and you've got included them more than once, you'll be facing multiple definition issue.
I have a little doubt regarding
C file with all static methods.
If all the methods [functions] are static, how to use them, anyway?
However, the way for you will be taking all the related .c files, compile and link them together to form the final binary.
Do not include separate c files. Just compile them separately as they are.
Suppose you have two files with code: main.c and include.c.
Rather than having #include "include.c" inside main.c, when you compile link the object files:
gcc main.c include.c
Related
I struggle to understand the way the C manual recommends to write functions in separate files.
When I want to write functions in a separate file with respect to the main, what I usually do is create a header file stuff.h and put everything there:
// this is the stuff.h file
int function_from_stuff(int b)
{
return 2*b;
}
then in the file main.c I will write
// this is the main.c file
#include "stuff.h"
int main()
{
int b=2;
int a=function_from_stuff(b);
printf("%d", a);
return 0;
}
and it all works well.
In the manual (chapter 4.5 Header Files in my edition) , they rather recommend to have several .c files where the functions are defined, and to use the header file only to declare them. So, in my trivial example, they would do something like
// this is the stuff.h file
int function_from_stuff(int b);
and then also create a another separate second_file.c file:
// this is the second_file.c file
#include "stuff.h"
int function_from_stuff(int b)
{
return 2*b;
}
Now, what I do not understand is how this can work, what the compiling order must be, and how I am going to signal the machine that I want second_file.c to be part of the program.
How exactly to do this is entirely dependent on which compiler you use.
what the compiling order must be
The order in which source files are compiled is not particularly important. Each produces an object file, which are then linked together. I suggest you read up on the compilation process if you want to know more about this.
how I am going to signal the machine that I want second_file.c to be part of the program.
This is generally done by simply adding adding second_file.c to your list of source files, but again this is compiler-dependent.
Let's say I have two files named "AA.c", "BB.c"
/* in AA.c */
inline void AA(void) __attribute__((always_inline));
void AA()
{
/* do something */
}
and then
/* in BB.c */
#include "AA.c"
extern void funcAA(void);
int main(void)
{
funcAA();
return 0;
}
does funcAA( ) also become inline???
no matter the answer is yes or no, could you explain some more about the under the hood??
including a .c file is equivalent of copying and pasting the file contents directly in the file which includes that, exactly like if the function was directly defined in the including file.
You can see what the compiler is going to compile by trying to compile your file with -E flag (preprocessor output). You'll see your function pasted-in.
So it will be inline just because of the inline keyword, and forced with the always_inline attribute even if the compiler would have refused to inline it because of function size for instance.
Word of advice: know what you're doing when including a .c file from another one. Some build systems/makefiles just scan the directories looking for files called *.c so they can compile them separately. Putting a possibly non-compiling C file there can make the build fail, and if it builds, you could have duplicate symbols when linking. Just don't do this.
If you want to do this, put your function in a .h file and declare it static so it won't fail the link if included in many .c files (each function will be seen as different)
I made up my project, saved main and c source in one file, and saved the header file in the include directory of codeblocks.
When I call my functions from within the project main function, it compiles beautifully.. but when I #include the header to other files for use, the compiler cannot find the functions. The prototypes are in the header, but their definition is in the source code which is in another file. I can access preprocessor constants and macros stored in the header, but the link between the function prototypes and their source code seems not to exist outside the actual project.
My goal was to make header files just like the existing ones I was using (stdio.h, stdlib.h, etc.). I can't find anything helpful on that anywhere. Help me, I've been at this for days!
I know I can make .c files with functions which is way easier, but I want the challenge, want to create lib files, and I'm a performance freak (as far as I know using .h files instead of .c files is much more efficient, can't remember why, though.)
header file:
#ifndef FIRO_H_INCLUDED
#define FIRO_H_INCLUDED
#include <stdbool.h>
#define MA_TA 69
bool checkprime(unsigned long long);
int square(int);
#endif // FIRO_H_INCLUDED
source code:
#include "firo.h"
#include <math.h>
bool checkprime(unsigned long long prime)
{
unsigned long long root=(unsigned long long)(sqrt(prime)+1);
unsigned long long i;
for(i=2; i<=root; i<3?(i++):(i+=2))
{
if(prime%i==0)
return false;
}
return true;
}
int square(int a)
{
return a*a;
}
I was hoping for an answer, not irony. I did read somewhere that segmenting code into .h files and source codes separately would somehow dinamically speed up the process of accesing functions, don't blame me for not knowing how that works. The checkprime function I actualy use, the rest is just for testing.
In codeblocks, you'll have to create a different project for the static lib and build it. Then, you may open your main project's linker settings (Project -> Build Options -> Linker settings tab) and add your library to the "Link libraries" list.
I know this is common in most languages, and maybe in C, as well. Can C handle separating several functions out to a separate file and having them be included?
The functions will rely on other include files, as well. I want the code to retain all functionality, but the code will be reused in several C scripts, and if I change it once I do not wish to have to go through every script and change it there, too.
Most definitely! What you're describing are header files. You can read more about this process here, but I'll outline the basics below.
You'll have your functions separated into a header file called functions.h, which contains the following:
int return_ten();
Then you can have a functions.c file which contains the definition of the function:
int return_ten()
{
return 10;
}
Then in your main.c file you can include the functions.h in the following way:
#include <stdio.h>
#include "functions.h"
int main(int argc, char *argv[])
{
printf("The number you're thinking of is %d\n", return_ten());
return 0;
}
This is assuming that your functions.h file is in the same directory as your main.c file.
Finally, when you want to compile this into your object file you need to link them together. Assuming you're using a command-line compiler, this just means adding the extra definition file onto the end. For the above code to work, you'd type the follow into your cmd: gcc main.c functions.c which would produce an a.out file that you can run.
Declare the functions in header files and then implement them in .c files. Now you can #include the header files into any program that uses the functions and then link the program against the object files generated from the .c files.
Say you have a file with a function that you want to use elsewhere:
int func2(int x){
/*do some stuff */
return 0;
}
what you would do is split this up into a header file and a source file. In the header file you just have the function declaration, this tells the compiler that that function does exist, even if it is in a different file. The header might be called func2.h might look like this:
#ifndef HEADER_FUNC2_H
#define HEADER_FUNC2_H
int func2(int x);
#endif /*HEADER_FUNC2_H*/
The #ifndef HEADER_FUNC2_H part is to make sure that this only gets used once so that there are no multiple definitions going on.
then in the source func2.c file you have the actual function itself:
int func2(int x){
/*do some stuff */
return 0;
}
and in any other file now that you use func2 you have to include the header. You do this with #include "func2.h". So for example if we wanted to call func2 from randomfile.c it would be like this:
#include "func2.h"
/* rest of randomfile.c */
func2(1);
Then the last step is to link the object file that contains the function with the compiler when you compile.
If you want to reuse functions across multple programs, you should place them in a library and link it with the rest of your code.
If you want to share the same definitions (e.g. macros, types, ...) you can place them in a header file and include them with #include.
Please refrain from directly "#include" function code into a source file, it's a bad practice and can lead to very problematic situations (especially if you are a beginner, as your tag suggests).
Consder that normally when you have a set of functions you want to share and reuse, you will need both! You will usually end up with a myfuncs.lib (or libmyfuncs.a) library and a myfuncs.h header.
In the programs where you want to reuse your existing functions, you will include the header and link against the library.
You can also look at how to use dynamic libraries once you have mastered the usage of static libraries.
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.