How would you #include multiple .h files to prevent warnings - c

I have a single main .c file with 4 .h files and .c files included into the main function. Like this:
#include <stdio.h>
#include "file1.h"
#include "file2.h"
#include "file3.h"
#include "file4.h"
int main(){...}
The .h files have all the declarations for all of their corresponding .c files. Some of the .c files do use functions from other .c files, for example "file4.c" uses some functions declared in "file2.h" and "file1.c" uses functions declared in "file3.h". I've tried declaring the same includes as in main in every .c file and tried reordering the include files, but I still get warning messages about implicit declarations of functions and incompatible implicit declarations.
I was wondering how you would use #includes in your large projects to eliminate warning messages. I'm using gcc as the compiler.

If you want import the .h file in a part of main() file, you must sure that you didn't import it anywhere.
For example:
file4.h use functions in file3.h
If you imported file3.h in file file4.h you have to not import file3.h in file main(). It's the duplicated definition.
If you have a lot of init files. You can import it in the only general file. And use that file in main().
Hope you like it ^^

Try this on all your own head files:
(beginning of your head file)
#ifndef _HEAD_FILE_NAME_H
#define _HEAD_FILE_NAME_H
...
<your headfile contents>
...
#endif
(end of your headfile)

Related

How to stop the inclusion of file imported in a file , the file in which the latter has been included in C

Like a.c has the code
#include "b.h"
b.h has:
#include "c.h"
c.h has:
void fun()
{
}
here i want to restrict a.c from acessing fun but I want b.h to access c.h
If file A.c includes file B.h, and file B.h includes file C.h, and file C.h contains function func - then A can call func - this is just how the language works.
What you can do instead is to move C.h's import into a B.c - which isn't included in A.c - and thus prevent the inclusion of func in A.c. But then you have to separate B into .h and .c - and compile B.c explicitly.
As John pointed out in the comments, you should add include guards to every .h file, e.g.:
#ifndef _B_H_
#define _B_H_
...
#endif
This prevents function declarations from getting reincluded. Also - it is bad practice to implement functions (e.g. int func() { }) in your .h files - instead you should include only their definition (e.g. int func();) and move their implementation to a separate .c file.
In the first place, this ...
here i want to restrict a.c from acessing fun
... has nothing in particular to do with header files or #include. If fun is defined as an external function anywhere in the program, then it can be called from anywhere else in the program, headers notwithstanding. This is merely a question of knowing the function's name and at least something about its signature. With that information, any source file can provide its own compatible declaration of the function to enable the call (and some compilers might even accept the call without a declaration).
If you want to restrict the locations from which fun() can be called (directly, by name) then declare it static, and move its definition to the (only) C source file from which you want it to be callable.
As far as ...
How to stop the inclusion of file imported in a file , the file in
which the latter has been included in C
... goes, you can't do that, strictly speaking. If a.c contains an #include "b.h" directive that is processed, and, in the context of processing that directive, b.h contains an #include "c.h" directive that is processed then the effect is to include the contents of c.h in a.c. Period.
If b.h contains an #include directive that you want to avoid being processed under some circumstances then conditional compilation directives (#if, #ifdef, #ifndef) are the way to do so. "Include guards" are a particularly common example, and as a matter of style and convention, every header should guard its body via appropriate include guards. If your c.h did that then it would resolve the duplicate function definition error you get from a.c directly including both b.h and c.h:
c.h
#ifndef C_H
#define C_H
// everything else ...
#endif
Of course, b.h should have its own include guards, too.
But even more importantly, avoid putting function or variable definitions in header files in the first place. Put only declarations into header files (and provide prototypes):
void f(void);
The actual definitions belong in regular source files (.c), and regular source files should never be #included by any other file. This is the way to share declarations of external functions and objects among translation units without inviting duplicate definitions.

Where is the best place to #include function definitions?

I am writing a rather large program in C and I had a question about header files. My main file includes my library header containing all of the function declarations. In the files that contain my function definitions, I have them include that same header file. When I compile, I link all the object files together.
It occurred to me that instead of having my definition files include the header file and then linking the results together, I could simply have the header file include the definitions at the END of the header file, like:
#ifndef HEADER
#def HEADER
#include <stdio.h>
#include <hdf.h>
... (function declarations)
#include "definition1.c"
#include "definition2.c"
#endif
What would be the benefits of doing it this way versus what I have now?

Macro used in a .c file getting compiled without adding the header file in which it is defined

I have a large project where some macro is defined as:
#define RECORD_COUNT 141 // in one file file1.h
Another file say file2.c is using this macro. But the file2.c is not including file1.h.
So is there a possibility that in on compiling the first file get pre-compiled is file1.h and the macro is added to the global scope. And this makes it possible to pre-compile the file2.c?
Very likely your macro definition are compiling before you are using it somewhere.
Just to check you can use pragma message to check if compiler touches that code.
http://msdn.microsoft.com/en-us/library/x7dkzch2.aspx
You do not need to include the header file directly to use it. There can be indirect includes as well.
For example,
Say file1.h has
#define RECORD_COUNT 141
file2.h has,
#include "file1.h"
...
...
If file2.c has #include "file2.h" then, you can use any macros or definition that are in 'file1.h' inside file2.c after that include statement.

Multiple definition of in C

I have a project written in C consisting of FIFO.h, FIFO.c, task.h, task.c and main.c (it's a basic queue).
When I compile my main.c using gcc under Windows it compiles and works just fine. However when I try to compile the exact same code in Eclipse, I get the following error for every function:
One example is:
In function `queue_new':
FIFO\Debug/../src/QueueFIFO.c:20: multiple definition of `queue_new'
src\main.o:FIFO\Debug/../src/QueueFIFO.c:20: first defined here
src\FIFO.o:
I honestly have no idea what additional information you guys could use so just tell me what to do.
main.c includes:
#include "FIFO.h"
#include "FIFO.c"
#include "task.h"
QueueFIFO.c:
#include "task.h"
FIFO.c:
#include "task.h"
#include "QueueFIFO.c"
task.c:
#include "task.h"
You are getting multiple definition errors because you are including your .c files in your .c files. It's the linker's job to make sure they come together. Good practice is to only include .h files in your .c files, and make sure the .h files don't include function definitions (only function prototypes).
By #includeing your .c files, you are defining the functions at least twice: once when FIFO.c is compiled, and again when main.c (which #includes FIFO.c, copying it verbatim into the text before compilation) is compiled. When it comes to link time, the linker sees e.g. queue_new() defined in both FIFO.o and main.o and barfs on the multiple definition of all the functions in FIFO.c.
In addition, as others mentioned, make sure you "guard" your header files to make sure they don't create circular #include dependencies. You can do that with #ifndef and #define as follows:
/* foo.h */
#ifndef FOO_H
#define FOO_H
#include "bar.h"
#include "baz.h"
/* header file contents go here */
#endif /* FOO_H */
This has the effect of only executing the contents of the file once, since FOO_H will be defined if it is included a second time, and the entirety of the file will be skipped over.

Nsight Eclipse 5.5 identifier is undefined

In a project with many .cu files and a .h file, I have some constants defined in my main.cu like this (shown just one as example):
__device__ __constant__ unsigned int x[1];
#include "second.cu"
... some code...
In the file second.cu I am trying to use that constant, like this:
cudaMemcpyToSymbol(x, y, sizeof(xx));
But Eclipse is giving me the error: identifier "x" is undefined.
I noticed that #includes in my main.cu, like the header.h, I need to specifically add in all the .cu files again. Which produced some redefinition problems that I solved using #pragma once.
I am new to Eclipse in general, found some complains about the CDT regarding include files not being indexed. I tried the Index Rebuild/Update/Freshen/Re-resolve method that worked for some in this regard, but with no luck with my problems.
Also, tried disabling the 'heuristic resolution of includes' in Properties -> Indexer. I thought I got it for a few moments but then the error showed up again.
Any ideas to solve this problem?
This is a C/C++ problem and have nothing to do with CUDA.
Generally people don't include source files like .cu .cpp .c. Only header files like .h should be included.
If you have a global variable int x need to be referenced in many source files. You could define it in one souce file as
// main.cu
int x;
...
declare it in a header file as
// main.h
extern int x;
...
and include this header file in all the source files you will reference that variable as
// second.cu
#include "main.h"
void foo() {
int local=x;
}
...
and
// third.cu
#include "main.h"
void bar() {
int private=x;
}
...

Resources