Since I got multiple classes and utility-functions I reuse on a regular basis, I started to create a static library for those parts.
Until now, most of those header files with class and function declarations #include the same "global" header file which itself #includes other header files (like <string> <windows.h> etc.).
As for me, It feels annoying to force a user to include more than one header file when only "actively" using the one which got the classes.
So I vanquished the global header file and included all the necessary headers into my own headers.
This worked in some way, but I encountered some problems regarding Winsock:
You need to #define WIN32_LEAN_AND_MEAN and ensure that the user won´t #include <windows.h> before those headers of mine, or multiple redefinitions will occur :/.
That´s why I wanted to ask You how You would do this? Or what approches You can think of?
I think you only have the option of defining a general header file that all other header files include and that defines WIN32_LEAN_AND_MEAN.
Otherwise you could instruct the user to include such definition in his own files, but his would be error prone.
As to inclusion of <windows.h> I think that it will not be included multiple times, since it has "include guards".
Related
I'm writing a library based on OpenVPN3, which is the C++ OpenVPN client implementation in header only, no cpp files. Therefore, I'm having to rely on having only one cpp file, which is the client itself, which includes a header that includes tons of other headers.
The problem is that, because of this, I cannot separate code into multiple cpp files. I'd like to be able for people to use my library, be it precompiled or compiled by them, but they cannot include the same headers on more than 1 cpp file or in the linking process there will be lots of redefinitions. There are also some static variables in the headers, for example.
If someone want to take a look at the number of things added into the 'master' header file: https://github.com/lucaszanella/libopenvpn3/blob/9b3440a736d90b671e9376d2d9e4911475e07112/src/OpenVPNClient.hpp
I know that there are some libraries like Asio that are also header-only and they're used without any problems by everyone.
Some techniques for not redefining a class or a function are to forward declare them but give no definition, but the problem here is that the person who's using my library is going to have to access its methods and everything. Is it possible to separate my methods from the ones used by my library on the headers?
you can put #pragma once on the most top of the file to avoid the same class clash due to being defined twice
If you do not want to duplicate import you can like tadman said:
at the top of the file
#ifndef HEADER
#define HEADER
//code goes here
#endif
I'm writing a library based on OpenVPN3, which is the C++ OpenVPN client implementation in header only, no cpp files. Therefore, I'm having to rely on having only one cpp file, which is the client itself, which includes a header that includes tons of other headers.
The problem is that, because of this, I cannot separate code into multiple cpp files. I'd like to be able for people to use my library, be it precompiled or compiled by them, but they cannot include the same headers on more than 1 cpp file or in the linking process there will be lots of redefinitions. There are also some static variables in the headers, for example.
If someone want to take a look at the number of things added into the 'master' header file: https://github.com/lucaszanella/libopenvpn3/blob/9b3440a736d90b671e9376d2d9e4911475e07112/src/OpenVPNClient.hpp
I know that there are some libraries like Asio that are also header-only and they're used without any problems by everyone.
Some techniques for not redefining a class or a function are to forward declare them but give no definition, but the problem here is that the person who's using my library is going to have to access its methods and everything. Is it possible to separate my methods from the ones used by my library on the headers?
you can put #pragma once on the most top of the file to avoid the same class clash due to being defined twice
If you do not want to duplicate import you can like tadman said:
at the top of the file
#ifndef HEADER
#define HEADER
//code goes here
#endif
in my current project I´m working with the arpackpp interface. The entire library is written in .h files, so that there is no need to compile the library. The problem I'm facing now - when I include some of the arpackpp header files in some of my files, which are not the main.cpp, I get the following errors:
/.../Files/Includes/../../../arpack++/include/arerror.h:163: multiple definition of ArpackError::Set(ArpackError::ErrorCode, std::string const&)'
/.../Files/Includes/../../../arpack++/include/arerror.h:163: first defined here
/tmp/ccruWhMn.o: In functionstd::iterator_traits::iterator_category std::__iterator_category(char* const&)':
/.../Files/Includes/../../../arpack++/include/arerror.h:163: multiple definition of ArpackError::code'
/.../Files/Includes/../../../arpack++/include/arerror.h:163: first defined here
/tmp/ccruWhMn.o: In functionstd::vector >::max_size() const':
for several arpackpp functions when linking all the .o files. As I have read in several threads the problem is that I actually include the instantiation of the functions, which should be normally avoided.
Because I don't want to change the whole library I included all classes and functions using arpackpp classes in main.cpp, which is getting quite messy. Is there a workaround to this problem? And why doesn't include guards (#ifndef...#endif) prevent this problem?
First of all, include guards do not help at this point as they only prevent multiple inclusions of a header in a "subtree" of your project files' dependency graph. In other words: If you include a header in two totally separated files of the same project, the c++ preprocessor will replace the #include <header.h> twice and independently by the code specified in the header. This is perfectly fine as long as the header only contains declarations.
In your case (and in the case of many other header-only libraries), definitions are provided in the headers as well. So unfortunately (as far as I know), there is no elegant way other than including definition-containing files once in your project. https://github.com/m-reuter/arpackpp/blob/master/include/README explicitly states which files contain definitions.
Some libraries, however, provide preprocessor macros to trigger the inclusion of definitions for the provided header files (e.g. https://github.com/nothings/stb). Maybe arpackpp provides similar mechanisms.
In general the easiest way to the work with header only libraries is to extend your code only using headers. Provided you use the correct header guards, this would remove the issue of multiple definitions of your code. If you have a large base of existing code then I would suggest that you rename all your *.cpp files to *.hpp (c++ header files) and then add suitable header guards. Furthermore a convenient way of handling this code of base is to create an additional header file config.hpp and include all your other headers in that file. Then in your main.c it is a simple matter of including the config.hpp file.
e.g.
// Config.hpp ------------------------------------------------=
#include "example.hpp"
#include "example1.hpp"
#include "example2.hpp"
// etc.
// main.cpp --------------------------------------------------=
#include "Config.hpp"
int main() {
// Your code here.
return 0;
}
Furthermore if you wanted to continue with your project structure it would be a simple matter of separating all your code into functions that needed to access arpackcpp directly. Then include them all into one *.cpp file, and compile into a *.o and link.
My team and I are working on a pretty large project with many classes with their respective header and source files. We are trying to consolidate all includes from both C++ libraries and the projects class header files into one file called "Includes.h" which is included in every header file. One problem I have encountered when doing this is that the class header files are basically including themselves. I have included #pragma once at the top of every header file. When I comment out the #include "Controller.h" in the "#Includes.h" file, the errors for "Controller.h" go away.
Please Please Please and Pretty Please do not do this.
Prefer forward declarations. Then the individual include files.
Otherwise you change one include file and it has to compile the lot. I.e. waste of time.
Bascially get each header file to be able to compile with a blank cpp file. Minimum dependecies.
I have a precompiled header stdafx.h which is used in all source files in my project. Thus all headers in the stdafx.h are available in all code files in the project.
What I'm unsure about is whether or not to re-include stuff thats already in the precompiled header. What do you guys think?
e.g.
stdafx.h
#pragma once
#include <memory>
my_class.h
#pragma once
#include <memory> // Re-include or not that's the question. Best practice?
struct my_class
{
};
typedef std::shared_ptr<my_class> my_class_ptr;
main.cpp
#include "stdafx.h"
#include "my_class.h"
int main()
{
}
I would include it so that the header could be reused in a project which has different stdafx.h Another way of stating this is each header should contain all the declarations (preferably forward ones) it needs on its own
There will not be any performance hit as the contents of the header will not be processed due to internal header guard (or for VS the #pragma:once in the header file.
In a header you should include everything, that is necessary for that header to be used separately. If you use std::shared_ptr in a header and that template comes from memory header, include memory header.
When you design a header your goal should be to make it complete, so that when someone includes it, he/she doesn't get errors caused by unresolved references. Don't worry that some headers might be included repeatedly. There are other mechanisms to protect against that.
BTW, use those mechanisms (like #pragmaor #ifndef/#define) in your header too.
The best practice would be to use forward declarations as much as possible. Having unnecessary includes might increase compilation time. Always include headers in a file if the implementation uses it even though it was included in a previously included file. This way, if some day you need to remove the header inclusion from the previous file, you will not cause errors in this file and the file won't need any modification.