As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have several C source files and headers. Some headers are for public use and some for internal use by library. I would like to separate them logically into folders so that headers for internal use do not mix with headers for public use.
Are there any commonly used patterns for that simple task?
here is a typical pattern, and it may depend on your compiler what is available to you... you have 2 types of include path during compilation:
User Header search path, denoted by double quoted #include "header.h" header names, these are typically just for the project that you are working on; as in you wouldn't address library headers this way typically.
System Header search path, denoted by angle braces #include <mylib/header.h>, this can also be used for your libraries...
lets imagine the following simple scenario...
Project A depends on Lib A.
in lib_a we have one c file and 2 headers...
lib_a.c, lib_a.h, and lib_a_internal.h
when you build lib_a.c you use the following includes:
#include "lib_a.h"
#include "lib_a_internal.h"
in your build script you will copy lib_a.h to include/lib_a/lib_a.h somewhere in your system headers path (maybe not in your real system headers, but a build specific one, depending on how atomic and sophisticated you want to be.)
You would also likely copy your lib_a.a (or .so or .dyld, or .dll) to lib/lib_a.a where lib is typically a peer of include above.
then when you build Project A you use the following:
#include <lib_a/lib_a.h>
Why not put them into separate directories and use the flags to fetch the appropriate ones during the build?
Leave the internal headers with the lib's sources and place the headers prototyping the lib's external API to /usr/include/<your lib's name without the prefix "lib">.
Alternativly put the external headers to /usr/lib/<your lib's name without the prefix "lib">/include and link /usr/include/<your lib's name without the prefix "lib"> to the latter.
This allows you to place additional files to you lib under /usr/lib/<your lib's name without the prefix "lib">/include. For example config settings in etc which then can be linked from /etc/<your lib's name without the prefix "lib">.
Related
This question already has answers here:
Header per source file
(7 answers)
Closed 8 years ago.
On most tutorial I could find on the web I have notice that everyone is creating header files for everything and never include a .c file.
I couldn't find any good explanation on the web about why you need the header file.
I have read that including the header file allows you to not repeat yourself which doesn't make sense to me. The header file IS a repetition of all the declaration of your implementation, if you include your implementation directly, then you avoid this overhead right!?!
Don't get me wrong, I can understand the use of header file when you are doing libraries : Several project can include only the header file and then linking to the same library (e.g. the standard library) thus ending up with a smaller executable. I just don't see the benefit of header file when you include something which is completly specific to your project...
Can you explain me the real benefit of header files?
Suppose you have a program built from 10 source files. If each one included all the code that was needed (including, presumably, the implementations of the standard C library functions it uses), you'd have lots and lots of multiple definition errors when you link all the bits together.
So, a header (normally) includes just the declarations. The object code for the corresponding source code is linked with the program, either as explicit object files or as libraries. This stops you getting multiple definition errors.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I want to know what is the difference between preprocessor directives and libraries in C?
So far, I know preprocessor directives are used to include external files. (I mean these external files can be Libraries?)
And libraries are ready made compiled programs already written for us. (Thus we need preprocessor directives to include them in C?)
Preprocessor directives appear in source code. There are many different directives. One of them is #include, which is used to include a header file. Header files contain a collection of declarations, often for functions and types (and sometimes variables) found in a library. However, a header is not a library.
Libraries are collections of object files that have already been compiled. The C standard does not recognize that libraries exist (but it does recognize the preprocessor and defines the required behaviour). Libraries are listed on the linker (compiler) command line, often using the -lname notation to locate a library name, with the -L option used to specify places to search for libraries.
Note that the majority of the functions defined in the standard C library are found by the linker without it needing to be told where to look for them. The exception are the maths function which, for historical reasons (primarily related to machines that did not always have floating point arithmetic built-in — sometimes they had FP coprocessors, such as the Intel 80386 + 80387, or sometimes they needed software emulation of the missing hardware). On many systems, you need to specify -lm to link the maths library; on others, you don't (the code is in the main system C library).
Generally speaking, headers are not found in the same directories as libraries (it would be a messy, unprofessional project that installed headers into the same directory as its libraries).
Especially in C++, there are libraries that do not have pre-compiled object files; the services are defined exclusively through the header. These are much less common in C. It is most sensible to regard the files as headers, not libraries. A header defines a set of services that can be used by the compiler. A library provides the support for such services. (If you think about it, or take a look in your system, you will find that <stdio.h> does not include the source for fprintf() — to take one example of many — but it does declare fprintf() in such a manner that your program can use it and so that the actual function from the standard C library will be used at runtime.)
Dynamic linking (the loading of shared objects, aka shared libraries or dynamic link libraries (DLLs)) where the library file(s) are not loaded until runtime, after the program is started up (after main() has been called) are another whole platform-specific bag'o'worms.
Pre processors commands do lots of things, one of those is include files, such as header files. Libraries mostly provide compiled code to do things for you, this is very very different. However, most libraries will require your code to include a header file from the library so that you code will know about the types and function available in the library.
there are a lot of preprocessor directives , I'll list some of theme here :
#define : is used to define constants or marcro (with or without arguments )
#include: which include files (using the " ") or libraries (using < >)
#if and #ifdef : used to compile only parts of code when certain conditions are filled (they are allways followed by #endif)
...
you can find out a lot more about preprocessor directive here
This question already has answers here:
Where to document functions in C or C++? [closed]
(10 answers)
Closed 8 years ago.
Suppose we have function (external only considered here) int foo(int a, char *b), normally there will be a header that goes with it documenting what the function does, what each parameter and return value does, etc. It'll probably be in doxygen format too. My habit is that such header should go into .h files because that's where the interface is defined and reader should have all the information in that place. But a lot of people keep such headers in C file where the actual implimentation goes. I've seen this in the Linux kernel code also. So was I wrong? Which would you prefer?
Although header files can be used in any which way, they are primarily a mechanism to enable external linkage.
You design an API that is meant for external consumption, and you put everything required to consume this API (constants, types, prototypes) in header file(s).
All the other stuff, that is a part of implementation, and doesn't need to be seen by external users, can go in the source files (if the usage is localized to one file), or private headers that can be shared between multiple files. The latter is another example of header files enabling external linkage, but for internal consumption.
The answer to this question is largely "it depends":
Depends on what? Who's reading the documentation, and how they access it.
If you're developing a program, then having the documentation inline with the implementation is probably OK, because anybody who wants to know about your program can access the source code and read about it. Your target audience is probably developers working on the program itself, so having the documentation in the C file, along with the bulk of the code they're working on, is a suitable approach.
If you're developing a library, the target audience changes (or you might have two target audiences). You still have the developers, who could make use of more detailed documentation as it relates to private implementation detail. You also have the users of the library, who only care about the interface that they're working with; from a code-browsing point of view, they typically only have access to the headers.
I put them in the .h file by preference when it's my choice, if I have a .h file. If I just have a .c file, I will document the functions when they are defined, simply because if I just have a .c file, I'm probably still coding, and I want to change the documentation if I change the code.
I feel that documentation and declarations go together in a separate file in a finished c project. Documentation in the code breaks up the code and can be redundant.
If I'm contributing somewhere, I'll follow the established convention.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a newb, like myself, to have great difficulty with searching the header files such as stdio.h for a function like getchar(). Somehow I picked up some information somewhere that I should not be afraid when looking in header files to "see how things work." (C++ Primer Plus, Stephen Prata)
I am very inexperienced with header files to say the least, and programmig in general.
In my attempt to find getchar() I found that stdio.h simply branches to more and more headers, and locating getchar() became increasinly complicated and time consuming, and I never found it. Clearly I am going about this all wrong, my intention was merely to find some source code for functions I am using.
My question therefore is: Where can I find source code to truly 'understand' what the standard functions are 'really' doing?
If you're looking for the declarations for variable order or other usage notes, just use an online reference or man.
If you're looking for the actual code, look into an implementation of the C standard library, like GNU's libc.
It's worth noting though, that implementations are not simple, and their graph of dependencies goes far and wide. They also tend to interact with the machine on a lower level than most of us are used to.
Consider libc's implementation of getchar:
int
getchar ()
{
int result;
_IO_acquire_lock (_IO_stdin);
result = _IO_getc_unlocked (_IO_stdin);
_IO_release_lock (_IO_stdin);
return result;
}
Probably not what you were expecting :).
(Note: No idea how good of reference that is for C -- it's just the one I typically use for C++.)
you shouldn't search the header files, you should use the man pages or MSDN help.
The C Standard does not mandate the standard headers files (like stdio.h) to physically exist. They can be just built-in.
If you don't know the parameters or the return value of a function, read the C Standard or the man pages.
In C header files are used (included) to pre declare functions. The functions that are predeclared may either be your own, where the implementation is in another (or the same for that matter) .c file, or an already compiled library. The stdio.h is an example of the last.
You should not have to look in the header file to find the function declaration. try using google typing 'man '
cheers
That is kinda like modifying the executable file explorer.exe to perform a simple action in Windows. Those are the base files, leave them be and write your functionality directly in your files. Also, if searching and altering files is an issue, make sure that you are using an IDE and not trying to do things by hand through notepad or another program like that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm writing a tool and I need to generate the callgraph for some C projects.
I was able to generate the callgraph of one file using clang, but I was not able to find out how to generate the call graph across the whole project which contains tens of header and source files.
Any tool that can generate the callgraph to a file that can be parsed will be fine. A usable library will be better.
Also worth mentioning, the excellent GNU cflow:
GNU cflow analyzes a collection of C source files and prints a graph, charting control flow within the program.
GNU cflow is able to produce both direct and inverted flowgraphs for C sources. Optionally a cross-reference listing can be generated. Two output formats are implemented: POSIX and GNU (extended).
Input files can optionally be preprocessed before analyzing.
Edit
As for the library request. You might like to "tweak" output.c and instead of printing do something else with the data. The internal flow is organised into output handlers, so I think writing your own handler could already do the trick. It's not out of the box though.
Turning my comment into an answer.
You can have a look at the assembly output and process that using a script. Assuming gcc on linux, you pass the -S flag to gcc and process the result with something like this:
perl -ne '/^([^. \t#].*):/ and $f=$1;/call\s+([^*]\S*)/ and print "$f -> $1\n";' *.S
This will give you a line for each static call, containing the calling and the called function. You could add a bit of boilerplate around that and feed the result to dot, or whatever you want to do with it.
You can omit the “must not start with a star” part of the regular expression to obtain some indication of indirect calls as well. You still won't be able to tell what functions will get called at that point, but at least you'll know that there is something more to know.