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__
Related
I'm creating a new project in keil to learn how to add files and headers and link them properly. I need some help in understanding the optimised way to add header files.
I've a main.h file, in that I've included FU68xx.h, adc.h and gpio.h file.
#ifndef HEADER_FILE
#define HEADER_FILE
#include <FU68xx.h>
#include "adc.h"
#include "gpio.h"
#endif
In "adc.c" and "gpio.c" file i've included only main.h file and I'm able to compile successfully. But is this the right way to do it? is adding main.h file in all the files cause multiple inclusion of header files?
If I add the main.h file under #ifndef HEADER_FILE in the "adc.c" or "gpio.c" file, i get error while compiling about undefined identifiers.
Multiple inclusion of the same header file is not a problem (and not a noticeable compile-time increase) if each header is appropriately protected with an "#ifndef" as you did.
Note that the name you used in that "#ifndef" must be unique (different in each header file), so the name "HEADER_FILE" is not very good - it would have been better to call it with a unique name, e.g., "INCLUDED_MAIN_H" (and other header files will use other names). Alternatively, all modern compilers support the "#pragma once" command which is better than ifndef in two ways:
You don't need to invent a unique name (and risk that it's not unique)
The compiler doesn't need to read the header file until the end just to look for the "#endif" - once it sees the "#pragma once" and knows this is the second time reading the same file, it immediately stops reading it.
But even though including the same header file is not a problem, including too many headers in a file that doesn't need it is a problem - it increases compilation time, and also increases incremental compilation time: If you change a header file, and a hundred other files include it, the build system (e.g., make) will need to re-compile all of these hundred other files. So usually I would recommend that each source file (.c) should include only the minimal set of header files that it really needs - rather than include some big "main.h" that includes everything.
This is a question of an embedded application, but I imagine the solution is language (C) based and not specific to the embedded compiler (XC16) I'm using.
Problem
I have a number of code files I am abstracting from a single project to create a shared collection of files that can be re-used across multiple projects. These files will require a config.h file in the main application to #define a number of parameters for that project.
Example
Files in project
config.h
#define BUFF_SIZE 4
main.c
#include "config.h"
#include <lib.h>
/*Application Code*/
Files in 'Library' (i.e. another folder NOT in the project structure)
lib.h
extern uint8_t Buffer [BUFF_SIZE];
lib.c
#include "lib.h"
uint8_t Buffer [BUFF_SIZE];
Question
This produces the issue that 'BUFF_SIZE is un-declared in lib.h'. My understanding was that the compiler would start in main.c load in the `#define' values from config.h THEN try to process the lib.h header. But it seems this is not the case.
Do I have to back reference the library to the config.h file? This seems to work, but it then forces the application to have specific file names.
Are there any good examples of how this sort of structuring should take place?
Additional Notes
The same issue arises when I try and map pin outputs for bit-bang functions. i.e.
config.h
#define DATA_OUT LATBbits.LATB4
lib.c
void SetPin(void)
{
DATA_OUT = 1;
}
Cheers :)
C code is compiled on translation unit basis. A translation unit being one single .c file and all the h files it includes. So you must include "config.h" from "lib.h".
You also need to use so-called "header guards"/"include guards" in every header. See
Creating your own header file in C
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.
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
In my application I use a static library with header file foo.h
In my build script I use a gcc -I flag -I./lib.
The foo library is in a directory ./lib/foo. In my main application I include foo.h as
#include "foo/foo.h"
Now I'm refactoring part of my application as a library, bar, that I expect to statically link to another application. This library bar depends on foo. With my current project layout, I could include foo in bar as
#include "foo/foo.h"
However, that would force users of bar to place foo in a directory called foo.
Is the standard thing to do in this case the following?
Add an -I flag to the build script that allows including foo in bar with just
#include "foo.h"
The reason for using folder structures with include files is to prevent collisions with header files of the same name. For instance, lets say I am using a library for encryption, and they have a header file called "status.h". At the same time I want to use a messaging library, and they have also have a header file named "status.h". They cannot coexist in the same directory and if you make the directory an include path it may not know which one you want to include. If you keep them seperate you can include both:
#include "encryption/status.h"
#include "messaging/status.h"
So the answer to your question depends on how likely you think the name of the include files will conflict with other include files of other libraries. If it will never conflict then what you are suggesting is fine. If it will conflict them make them use the directory.
Happy coding!