I have a project that uses Boost.Asio and the Media-Decoding-Samples that come with the Intel IPP-Library. The problem is the following. If I compile the project without defining WIN32_LEAN_AND_MEAN, Asio complains with the infamous "winsock.h already included" error. If I define the macro, a header in the other library has undefined types, because it relies on windows.h including winsock.h. I tried adding winsock.h to that header manually, but this makes Boost.Asio cry out again. The only solution I can think of would be to go through every compilation unit and make sure that Asio is always included first. Due to the size and complexity of the project (and the uglyness of that solution) I would like to find a better way.
Thanks in advance !
you can get around this if you split up your source and make sure not to use some kind of common header in your application in which you incude both Asio and IPP. So the source files needing Asio include Boost headers, the source files needing IPP include the IPP headers, but the header files for your classes that need to refer to both should not include any external headers, and use forward declarations if needed.
" a header in the other library has undefined types"
How many? How complicated? Perhaps you could define those types?
Related
I coded a program importing and making use of many headers from the boost library. After that the compilation time went from 1-2 seconds to 30s+. Since I am always importing the same library I was wondering if there was a way to compile them once and for all to speed up the following compilations.
I am very unfamiliar with shared/static libraries and could not find a tutorial answering my question.
I do not mind have a much larger executable in case this is the price to pay.
If you include boost headers in one of your program's headers, and all / many of your program's .cpp files include that header, then the boost headers end up getting included in all of your .cpp files, and get compiled once for each one of them.
To avoid this, you can try to only include boost headers in (one) or a few .cpp files in your project.
You can also use PIMPL idiom, also known as "compilation firewall". The idea is that you expose only an interface in the header that your program uses, and if the implementation requires boost things, then that appears in the .cpp file only so you dont end up including boost everywhere.
Note that header-only libraries don't really have to do with shared vs. static. With shared / static libraries, you have object code of some kind which was obtained by compiling the libraries in advance. With header-only libraries, what you are importing is just template definitions into your code, and your compiler makes use of them. It's closer in spirit to static than to shared linking, but it's not really either.
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.
Is it possible to include the C++ standard library in a single statement, or must you do it header by header?
No, there is no shortcut to include all of the standard headers. You must generally include each one that you require separately.
It's possible to create a single header file that includes all standard library headers—something like all.h. However, you should consider whether doing that is a smart move, as it will extend compilation times significantly.
Also, make sure you understand the C++ compilation model before you make such decisions. If you don't already know, find out what's a translation unit, an object file, what the linker does, what's the difference between including a library header and linking a library.
Under Visual Studio you could put all such header files inside your precompiled header file. Since this file is included by all your files all stl hearders would be available everywhere. If all the includes in precompiled header file are from external libraries, then precompilation should speed up compilation times.
No, there is no shortcut to include all the standard headers.
Maybe you can include all the headers in your own all.h, then #include<all.h>,but it is not recommended.
GCC has a header called <bits/stdc++.h>, but this should never be relied on in a typical context.
As noted by the OP, this is the kind of thing you might only want to use in a competitive programming contest, where only running time matters.
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.
Why do we need to add both includes and libs to the compilation?
Why doesn't the libs wrap everything in it?
Header files define interfaces; libraries provide implementations.
The header for a library is going to tell your compiler the names and signatures of functions provided by the library, the names of variables provided by the library, and the layout of classes provided by the library.
The library itself is compiled code which is executed at run time. Using the header during compilation allows your compiler to generate compiled code which knows how to invoke and communicate with the existing library code.
A header file (usually) only contains declarations for classes and functions. The actual implementations are built from CPP files. You can then link against those implementations with only the header declarations available.
I'm guessing this is your way of handling the question you asked at How to make #include <mysql.h> work?
Unfortunately, I think the better solution is to either learn more about C++, or learn more about Google, before posting absolutely everything to this site.