I was wondering, when making your own static library, is it a good idea to combine all the header files into one wrapper header file? For example, let say I have a bunch of *.h and *.cpp files, which I compiled into *.lib files. Is it good practice to make a wrapper header file, so when I write include, I only have to include one header, which will include everything else, which I may or may not need. Does this bloat up the *.exe file, which would have been linked to the library file with the stuff that wasn't being used?
If it is a static library, it is going to become part of exe anyway whether you make it one header or several headers. However, from a design perspective, it is better to keep headers separate so that the user of that lib includes only the headers that he specifically needs.
Related
I couldn't really find anything on Google or SO about this. I don't know if it's because it's uncommon, or because I am using the wrong terms to search. I read this question here, but it didn't really answer my question.
So what I am doing is trying to build a library on top of SDL for C++. Now what I can't seem to figure out is how to make projects that use my library be totally independent from SDLs files except the dll.
When I make my library, I link with SDL2.lib, and SDL2main.lib. I include all of SDLs header files into my libraries files. When I build, it generates my library file; GGL.lib.
But when I want to test my library in another project, I have to include all of SDLs header files, because in my project's Window.h, it includes SDL.h. I am wondering if there is any way for me to make my libraries header files independent from SDL except for the dll.
You obviously need to avoid including SDL header files in header files of your library. Include them only in source files, where possible. This removes redundant dependencies and speeds up compilation process. But you want complete independence, so if you can't remove one #include directive, you failed.
If you need to declare a pointer of an SDL type in your header (like one usually does with SDL), forward declare it. That type will however remain incomplete to the users of your library. In case your library is object-oriented, there's Pimpl Idiom, which is based on the same principle - this hides everything.
Is there some kind of generally agreed-upon standard for how C++ libraries should be structured, file-wise? I'm thinking my library would be static. It's fairly expansive, so right now, I have classes split into different files. Each source file has a header file to go with it.
I don't want the end user to have to #include every one of my header files, obviously. I thought about having a single header file named "libraryname.h" that just #includes all the header files for the user, but I've never seen any other libraries do that, and I fear that's for a reason.
I've seen libraries use a single header file and multiple source files, which seems simple but also a bit cluttered. I've also seen libraries completely nix the idea of separating source and header files and just have one file with #define guards that has all the code. That seems like a pretty good way to dramatically increase compile time, which I'd like to avoid, but if there's a really compelling reason to do libraries that way, I'd love to know it. Any advice on what style to use would be appreciated!
Having a single header file really slows down your build (i.e. a single change in one of your class declarations requires a full library build).
Also, you'll find that most source files will not need all the headers. You can also use forward declarations too which helps.
If your compiler supports precompiled headers, then that is the place to put all standard C++ library includes. But, don't put your headers in there or you'll force a whole library rebuild on a single change.
We can include < iostream > and we do not care about its cpp file, but why can't we do the same for our own classes ?
So if my project uses 50 custom classes, not only do I have to have 50 includes, but also have to compile/link 50 cpp files along with them (and clutter the project tree).
Q: Is there any way to use custom headers the same way we use standard libraries ?
In other words is there a kosher way so that we do not have to add all those cpp files in the project. I want to only include ClassSnake.hpp which in turn knows where to find ClassSnake.cpp which links to ClassVector.hpp which knows how to find ClassVector.cpp ... all in an automatic daisy chain without me having to explicitly add those cpp files in my project tree.
Edit: I am not worried so much about the cpp files recompiling. My issue is with having to remember which class internally links to which other class, so that I can properly include all those hidden cpp files in the project tree ... and clutter the tree.
Not really.
What you're missing is that your compiler toolchain has already compiled the bits <iostream> needs that aren't in the header.
Your compiler (linker really) just implicitly links this code in without you having to specify it.
If you want to clean up your project tree a bit, you could create other projects that are libraries of code for one main project to use.
Headers do not (normally) provide implementations of things (functions, classes), they must be implemented somewhere if you are going to use them.
When you include your own header, you include your own sources in order to provide the implementation. Straight forward enough there.
When you include a standard header (such as iostream), the implementation is in the libraries you include (either implicitly because the compiler just does it, or explicitly through compiler/linker options).
As an extention to Collin's answer, you could always offload "shared" code to a shared library, and then reference the header files and lib files in your other projects. The lib files will only come in to play at the linker stage, as all those other pesky .cpp files have already been compiled.
If this is is just a self-enclosed project with no other commonality, you're just going to have to suck up the fact you have to provide an implementation :)
First of all if you use a system such as make then it will identify that the .cpp file has not changed and therefore the compiler does not have to reconstruct the object file.
You can also create your own static/shared library. The method to do this depends on the platform. If you go down this avenue then all you need is the header file along with the library.
Please Google on how to construct how to make a library for you particular platform.
Actually, if you have a decent build process cpp files that have not changed will not be compiled again. They only have to be linked. If you don't want that either you need to create your own libraries. It can be done, is just a bit more involved.
Edit: This question might help you if you want to create your own library.
So answer to edited question: Yes, you can avoid having all those cpp files in the project but only if you don't want to change them. In this case you can just create a static or dynamic library and you will only need the symbols for linking. In that case you would create another project to compile everything into such a library.
STL code like "iostream" is made of templates no code is actually generated until instances of the templates are created.
I have a series of small library "modules" designed to handle very specific tasks. A single module usually consists of just a .h and a .cpp, and possibly another set to provide relevant non-friend, non-member functions that the user might find useful.
For example, Foo.h might declare a class called Foo, that Foo.cpp defines, and FooUtilities.h might declare a function that uses Foo which is defined by FooUtilities.cpp.
Normally to use these modules in my programs, I add the .h and .cpp to my project and #include the .h in whatever files need it. However, for larger programs that use more potentially-interdependent modules, this is growing to be a big inconvenience. Therefore, I'd like to compile it all as a single monolithic static or dynamic library so I can just add the library file to my project, set the header search directories to folders that contain the aforementioned .h files, and compile.
Seems pretty simple, right? All I'd have to do is start a new project with a static/dynamic library as its build target and then add all the appropriate files. The .cpp files, which #include the .h files anyway, will be compiled and added to the final product.
However, some of the modules use templates and therefore have to use .tpp instead of .cpp. The .tpp files are only meant for organization and are #included by their respective header files, which is the opposite of how the normal modules are handled. Because of this, just adding them to my library project won't compile anything.
How can I work around this? Should I have a CompileThis.cpp file that includes all the modules that use templates? If so, should this file also include the non-template modules? It seems like this could rapidly become an organizational mess.
Many compilers cannot "precompile" templates into libraries. My best suggestion is to treat them like header files; header files are not compiled into libraries, they are just included.
I compile code into a library when the amount of changes is minimal. This often speeds up the build process since those files don't need to be compiled again (and again...).
Should I have a CompileThis.cpp file that includes all the modules that use templates?
Yes - you'll still need an object to link. It's also nice because it will perform the syntax/instantiation checks (assuming your depends are properly ordered).
If so, should this file also include the non-template modules?
that depends on the structure.
at minimum, it should include/define what it must export (and their dependencies).
it should often include the headers represented by the module, in order to easily detect errors issues at the package level.
ideally, you'll add all necessary concepts and some instantiations (in some cases).
this makes it easier to maintain, and will not require major restructuring when you realize you have moved from needing 0 exported symbols to needing one or more.
I know precompiled headers are used for speeding up compilations, but are there any do's and don'ts to what files I should include in them? For example, I have a project that uses a lot of boost libs so I just include the boost header files in stdafx.h (I'm using VS2008). Should I include every standard header file in them, too? Will this increase the size of my executeable even if I, for example, include <vector> but never use std::vector? Is it a bad idea to include my own project's header files in stdafx.h?
Generally speaking, every header file that you use across the application and that doesn't change often should go into the precompiled header file. This will speed up compilation because the precompiled header file gets compiled only once.
If you add a header file which changes often, you'll miss the point of the precompiled header file, because this often-changing header file will cause your whole project to recompile, possibly unnecessarily.
Specifically, defines a template class, so if you won't use std::vector, the overhead will not be big. However, I would advise against adding header files - however standard and generic - if you don't really need them. There IS some overhead to the compilation time, the binary size, and it could cause conflicts later in the project, so why add something if you don't really need it?
Pre-compiled headers don't affect the size of your executable, only the compilation speed. Since they are pre-compiled, they don't have to be re-compiled all the time. Windows.h is the primary beneficiary of this feature.
It's a good idea to include the c++ standard header-files and the boost library headers and any other headers from third party libraries that you frequently use. This will not affect the size of your executable.
However, you should not include headers from your own project, since the whole project needs to be rebuild whenever you make changes in these headers.