We have been learning C and it might seem like a stupid question to ask.
I want to know who exactly writes header files. I know that they have predefined functions in them and can be accessed as per need.
The header files that come with your compiler are written by the authors of your compiler and C library. Header files for third-party libraries are written by the authors of those libraries. Header files for your software are written by you.
Header files are written by the programmers to export the library functions or class. Header files may used to define classes, macros , member functions, structures, variables etc. if you make some changes in header files of your library it may affect your library functions. You have to recompile the library before use.
Related
Recently I have been working with the TIVA C series launchpad board which has a Cortex-M4 chip on it. I use the Code Composer Studio as my IDE.
There is a lot of confusion going on right now because through trial and error I see that in order to use certain functions that the chip manufacturer provides, I will need to include the .c file instead of including the .h file.
This caught me off guard and I admit that I am not an expert programmer or an expert when it comes to compiler design. But does anyone know why a compiler would need the .c file instead of needing the .h file?
The .h file is still being used since it has definitions in it that the .c file requires.
Perhaps a better question may be this:
When there is a .h file and a .c file, do you include the .c file in your code or do you include the .h file?
My trial and error exercise is telling me that you must include the .c file but I am totally in the blind on what the actual rules are.
Sorry if any part of this is too vague. I would be totally fine with sharing my main.c file so you can see how I included the files but I felt that my question is more of a question regarding what the general rules are for including files when there is both a .h and a .c file.
Thank you for any time you can give me in helping me understand this issue.
EDIT: Why the down votes? I thought coming here for help was what this place was about?
It is important to understand that substantially all C programs are built from multiple source files. Under some circumstances many of those sources are pre-compiled into one or more libraries, but it is quite common that building a C program will involve also building multiple C source files and linking those to each other and to appropriate libraries to produce the final result.
It is also important to understand that although C permits multiple compatible declarations of functions and file-scope variables, it permits only one definition of each distinct function or variable anywhere in an entire program. This is the primary reason for the convention of placing declarations into header files (ordinarily named with a .h extension). Any number of source files that contribute to a given program may #include the same header file, but at most one of them could #include the source file that contains the corresponding definitions, and then only if that file were not included directly in the build.
It may be possible to write your main source file so that it #includes the .c files containing all the needed definitions directly, in which case it is not necessary to include the headers, but you cannot have two separate source files doing that contribute to the same program if that produces duplicate function definitions. Ultimately, too, this approach may fail, for there can be limits on how large and complex a source file a given compiler can manage.
If there are header files accompanying the chip manufacturer's C source files, then your own source files should include only those headers. You should be able to build object files from such sources just fine. To build executable programs, however, you must also build the chip manufacturer's C sources, and link them to your own. It would be sensible to create a library containing the chip manufacturer's sources and to link that, but it would also work to build the needed source files directly for every program. Your IDE should have support for both options.
I came onto a project that employs the method of using a header file MyProject.h that has all the headers of each .c file. Each .c file has their own header file that has #include "MyProject.h", whatever libraries are needed, and any other declarations necessary for the file.
To me it seems redundant and somewhat unnatural, but it compiles and subsequently runs as expected. My thought is that the compiler would be doing way more work than necessary and is possibly over-bloating the .exe. What are the disadvantages, if any, to doing this?
A subsequent question I have is, say I included a library like Time.h in one file using the above example. Will the compiler only build Time.h once into the binary or for every file now because of MyProject.h? What about with structs, enums, etc...?
To have such a header file is poor practice and bad design. The problem is that it will create a tight coupling dependency between every single file of your project, even if they are completely unrelated.
Good program design is to create autonomous modules that only include the resources they are using. They should do this from their own h files, to document exactly which dependencies a particular module has.
The main downside is increased build times. Every source file includes every header of the project, whether it needs it or not.
It's also conceptually unclean. A source file should include the headers it needs. It should be possible to search for a header's name to find the parts of the source code that uses these facilities. Minimizing unnecessary includes is evidence of a loosely coupled system. However, include-what-you-use is hard to enforce, because you cannot prevent transitive availability of facilities through headers in C.
It should not lead to increased executable size. Even if the headers contain code (which is rare in C, but common in C++), the linker should eliminate duplicates and remove unused code.
All previous answers were clear enough, but.
The main disadvantage of "one big header file" is the problem with code reusability. For example, you've created some module as a part of your application. Let's say, this module implements API for some hardware. And then you want to make another application, which should use this module.
In this case you have to remember which header files you have to include to compile this module, or, if you just copy your previous "big header file", it requires a lot of unnecessary third party libraries and header files.
Nobody wants to spend a lot of time to make some module working. It's much better if you can use it right out-of-the-box, isn't it?
Most of my libraries have one precompiled header containing external includes and one "main" header for each library that contains the precompiled header items + all the .h files for the library in question. All of my .cpp files first include the precompiled header and then the main header.
That's it. None of my other .h files have any includes in at all. My .cpp files only include these two headers. Other libraries that need to use the library will #include that same main header.
Doing this has greatly simplified header file headache/complexity issue for me though I would add that most of my libraries are relatively small in the grand scheme of things. I don't know if this would work for a very large (monster) project. Perhaps not.
The way this works is actually quite nice. Others above, concerned about "coupling" want to minimise it, but if you don't include any headers at all you're 100% uncoupled, even from your dependencies. If you want to reuse the class, use the library that contains it.
Simple.
This is a complicated post so please be patient. I have tried to condense it as much as possible...
I am coming to XC8 from using a different tool chain for PIC microcontrollers. With the previous compiler, setting up and using my own libraries and using defines across those libraries seems to be much easier.
I want to write my own libraries of functions for re-use. I also want to store them all in a directory structure of my own choosing (this is so that they sync automatically between multiple machines and for various other reasons). Here is a simplified fictional file structure.
\projects\my_project //the current project directory
\some_other_directory\my_library\comms_lib //my communications library
\some_other_directory\my_library\adc_lib //my ADC library
Now let’s say for arguments sake that each of my libraries needs the __XTAL_FREQ definition. The frequency will likely be different for each project.
Here are my questions:
What is the best/most efficient way to tell the compiler where my library files are located?
Short of adding __XTAL_FREQ to every header file how do I make the define available to all of them?
Likely someone is going to say that it should be in a separate header file (let’s call it project_config.h). This file could then be located with each future project and changed accordingly. If the separate header file is the answer then question that follows is, how do I get the library headers (not in the same directory as the project) to reference the project_config.h file correctly for each new project?
Thanks in advance, Mark
If you are using MPLABX, you could consider making one or more library projects for your libraries, which can then be included from other MPLABX projects.
As for a global definition of __XTAL_FREQ, I'm thinking that it should be possible to pass a symbol definition to the command line, not sure though.
please, could someone explain to me a few basic things about working with languages like C? Especially on Windows?
If I want to use some other library, what do I need from the library? Header files .h and ..?
What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
To use another library, what is preferred way? LoadLibrary() or #include <>?
There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
How do I create one big .exe? Is this called "static linking"?
How to include some random file into .exe? Say a program icon or start-up song?
How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Well, so many question... Thanks for every info!
1: If I want to use some other library, what do I need from the library? Header files .h and ..?
... and, usually a *.lib file which you pass as an argument to your linker.
2: What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
This might be useful: Static libraries, dynamic libraries, DLLs, entry points, headers … how to get out of this alive?
3: Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
Yes, it matters. For interop between compilers, the normal way is to use a C-style (not C++-style) API, with well-defined parameter-passing conventions (e.g. __stdcall), or to use 'COM' interfaces.
4: To use another library, what is preferred way? LoadLibrary() or #include <>?
#include is for the compiler (e.g. so that it can compile calls to the library); and LoadLibrary (or, using a *.lib file) is for the run-time linker/loader (so that it can substitute the actual address of those library methods into your code): i.e. you need both.
5: There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
If it's only source then you can compile that source (once) into a library, and then (when you build your project) link to that library (without recompiling the library).
6: How do I create one big .exe? Is this called "static linking"?
Yes, compile everything and pass it all to the linker.
7: How to include some random file into .exe? Say a program icon or start-up song?
Define that in a Windows-specific 'resource file', which is compiled by the 'resource compiler'.
8: How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
Yes.
9: If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
I don't understand your question/example.
10: What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Yes.
If I want to use some other library, what do I need from the library? Header files .h and ..?
You need header .h or .hpp for C,C++ although some languages don't require header files. You'll also need .a, .so, .dll, .lib, .jar etc files. These files contain the machine code that you linker can link into your program. Goes without saying that the format of library is must be understood by you linker.
What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
dll and .a are library files, that contain code components that you can link into your own program. a .exe is your final program into which .a or .dll has already been linked.
Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
Yes, it is important that the library that you are using is compatible with your platform. Typically Unix libraries will not run on windows and vice versa, if you are using JAVA you are better off since a .jar files will usually work on any platform with JAVA enabled (though versions matter )
To use another library, what is preferred way? LoadLibrary() or #include <>?
include is not a way to use a library its just a preprocessor directive telling you preprocessor to include a external source file in your current source file. This file can be any file not just .h although usually it would be .h or a .hpp
You'll be better off my leaving the decision about when to load a library to you runtime environment or your linker, unless you know for sure that loading a library at a particular point of time is going to add some value to your code. The performance cost and exact method of doing this is platform dependent.
There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
If you have source code you'll need to recompile it every time you make a change to it.
however if you have not changed the source of library in anyway there is no need to recompile it. The build tool like Make are intelligent enough to take this decision for you.
How do I create one big .exe? Is this called "static linking"?
Creating a static .exe is dependent on the build tool you are using.
with gcc this would usually mean that you have to you -static option
gcc -static -o my.exe my.c
How to include some random file into .exe? Say a program icon or start-up song?
Nothing in programming is random. If it were we would be in trouble. Again the way you can play a song or display an icon is dependent on the platform you are using on some platforms it may even be impossible to do so.
How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
You'll need a header file with all your function prototypes and you can split you program into several .c files that contain one or more functions. You main files will include the header file. All source files need to be compiled individually and then linked into one executable. Typically you'll get a .o for every .c and then you link all the .o together to get a .exe
If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
Yes one library may require another library however its not advisable to package different libraries together, you may be violating the IPR and also for the fact that each library is usually a well define unit with a specific purpose and combining them into one usually doesn't make much sense.
What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Again depends on the platform, usually on most OS the memory will be recovered after the program dies but on certain platforms like an embedded system it may be permanently lost.
It always a good idea to clean up the resources your program has used.
In all seriousness, the place to go to learn how to run your local environment is the documentation for your local environment. After all we on not even know exactly what your environment is, much less have it in front of us.
But here are some answers:
1. You need the headers, and a linkable object of some kind. Or you need the source so that you can build these.
3. It matters that the library is in a format that your linker understands. In c++ and perhaps other languages, it also needs to understand the name mangling that was used.
6. Forcing all the library code to be included in the executable is, indeed, called "static linking".
7. There is at least one StackOverflow question on "resource compilers".
Is there a cross platform way to selectively export certain functions and structs from a C project which builds a shared library?
I want to do in a way that does not require a specific build system (the visibility should be defined in the code, eg as a macro), and in a way which both GCC and MSVC can understand.
Thank you.
Strictly no, of course, because the toolchains aren't the same.
But people do this. The complexities are that in windows, you need to
specifically tag the declarations of functions you want exported from
a DLL with __declspec(dllexport) in the location in the library where
the function is defined and __declspec(dllimport) in the locations
in client code where the funciton is referenced. Because standard
C practice has only one declaration in a single header file, this
means that you generally need to do some macro work to have a single
prefix that works in both locations. It seems like every project
picks its own standard for this.
On the Unix side, you don't need to tag exports at all, which is nice.
This is because every non-static function is exported by default,
which is not so nice. Often you can get away with this as long as
your non-public/non-static symbols have sane prefixes, which is what
most projects seem to do. If you need finer control over your
exported symbols, you can use a Solaris-style "mapfile" with the GNU
linker's --version-script (-M under solaris) argument to define explicitly which symbols should appear
in the external namespace.
There are a few more gotchas between the platforms, like the way the
per-library global namespace works and the handling of
startup/shutdown code. Basically, it's a rats nest that can't be
sanely explained in a post this short, but as long as you're careful
that your library contains simple functions and your namespace doesn't
pollute, you shouldn't have much trouble. Look to some of the more
popular cross-platform shared libraries (e.g. Qt, Glib/Gtk+, anything
distributed with msys, etc...) for guidance.