I try to include headers from a library in different files of my project and I get multiple definition errors on some functions of the library.
After reading the answer to this question I think the problem is that the functions are implemented directly in the header files of the library.
In particular I want to include the files codecfactory.h and deltautil.h from FastPFor. I don't know if it is relevant for my problem but I include it into my cmake project with this code in my CMakeLists.txt:
include_directories(../../FastPFor/headers)
add_library(FastPFor STATIC ../../FastPFor/src/bitpacking.cpp
../../FastPFor/src/bitpacking.cpp
../../FastPFor/src/bitpackingaligned.cpp
../../FastPFor/src/bitpackingunaligned.cpp
../../FastPFor/src/horizontalbitpacking.cpp
../../FastPFor/src/simdunalignedbitpacking.cpp
../../FastPFor/src/simdbitpacking.cpp
${HEADERS}
)
Everything works fine if I just include the files once. But as soon as I use them in two .cpp files I get these kinds of errors:
CMakeFiles/dbgen.bin.dir/queries/Query5.cpp.o: In function `vsencoding::BitsWriter::BitsWriter(unsigned int*)':
Query5.cpp:(.text+0x8420): multiple definition of `vsencoding::BitsWriter::BitsWriter(unsigned int*)'
CMakeFiles/dbgen.bin.dir/queries/Query13Naive.cpp.o:Query13Naive.cpp:(.text+0x7a50): first defined here
Is there any way I can fix this without having to change the FastPFor code but only my own?
The question you linked to says it all - there is no way to solve this without modifying the headers (or just include them in only one source file).
For instance this line defines a non-inline constructor in a header. Including it in more than one translation unit would result in a violation of the ODR rule.
One way to workaround this would be to change your project to header only style, i.e. moving your implementation to header files. In this way you can keep (more ore less) the structure of your project.
However, this is definitely not a nice solution... The whole project needs to be compiled after every small change to one of the headers...
Related
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.
I am starting some work using a third party library and when building it in Visual Studio 2010, I noticed I was receiving this linker warning many times (LNK4221). I looked at the sources used in creating the object files that were being linked and found that all of the implementation for these is located in the header files. Interestingly, I also noticed the project included corresponding .cpp files containing only a #include for the header with the implementation.
I am curious - what is the point of this and why would I want to use this technique? If the .cpp files aren't adding any value to the project, why shouldn't I just remove them to get rid of the linker warnings?
I tried searching for similar questions, but didn't find anything of interest. If you know of any, please link them.
Was the single #included file stdafx.h? I. That case, you're dealing with precompiled headers. The normal setup is for one .cpp file having "generate precompiled headers" compiler option, and the rest of the .cpp files in your project having "use pch".
I'm using this to make sure, that the header is at least in one file included at the first position. By doing so, I make sure that the header is compilable on it's own.
To convence the linker to not issue a warning, one could use an external variable with a very large variable:
int variable_with_a_name_that_includes_the_file_name_somehow = 42;
I just started learning C++ with Dev C++ as my IDE. One of the tutorials I'm using has a page in it about compiling a program made up of multiple files. It's simple stuff at this point, I have one file with a function in it, and the other file has all the other required code to call the function and output the results. The problem is that the tutorial doesn't tell me how to join these files so I can compile the program and have it work. There's seems to be multiple ways of doing this and I'd like them all but I'm mainly look for the simplest one right now.
I should also mention that I'm new at this so please try and keep your explanations simple and understandable.
In general, you would add both .cpp files to your project under the same target. It IDE will automatically add both files to the build and link them together.
That said, Dev-C++ is very, very old and unmaintained. It has not seen updates in several years. I strongly urge you to use a different IDE. There are many to choose from, including a fork of Dev-C++ called wxDev-C++. I'd actually recommend Code::Blocks or Visual Studio Express, which are both much more modern and have better support for debugging and many other features.
I am not sure of Dev-C++, but the concepts remain the same. So, here is how you can try to get both the files to work together
Each C++ file is a compilation unit - meaning, the compiler will convert one .cpp / .cxx file to one .obj / .o file (on Windows and Linux (or any Unix)) respectively
The obj files, called the object files contain the machine code (am skipping few internal details here) for the classes and functions present in that particular file
If you want to access the functions present in a different compilation unit, you need to link those two object files
Linking is a term that is used to, well, link two object files
There is a separate process (other than the compiler) which does the linking of the object files
So,in your case, you need to use the dev-c++ compiler and create separate object files
Then using the linker you link both the object files to create the final executable
If there are functions that exist in the .cpp files that you want to reference, you use the header files. The header files contain the function/class declarations. The .cpp files will have the implementations. So, in one of your .cpp file, (say) A.cpp, you include the header B.hpp and use the functions in the B.hpp file. The inclusion of headers will tell the compiler that the function declarations exist elsewhere and that the linker will take care of stringing all these references together to create the final executable.
Hope this helps, else, please don't hesitate to mention the files you are using and I can suggest how to link both the .cpp files together.
You must include the other files by using the #include preprocessor directive
in the top of the file where you have the main() function
For example:
#include "filename.h"
...
/* rest of code containing main function goes here */
...
#include "path/filename.c"
main
{
...
...
...
}
I have a Visual C++ solution with 2 projects AlgorithmA & AlgorithmB and both share a common header file RunAlgo.h with the class declaration. Each project in the solution has its own unique implementation for the header file.
I am trying to compile a DLL out of the common header file RunAlgo.h and add reference to this DLL in the projects AlgorithmA & AlgorithmB. I have then included separate RunAlgo.cpp definition file in both my projects. The problem is that I am getting linker errors while compiling the new DLL project which has only the header file.
So, the question is
Can a header file with only class declaration be compiled into a DLL (Similar to class library containing an Interface in C#)?
For the above scenario, is there a better approach to reuse the common Header file among projects?
Should the above method work (re-check my code?)
1 & 3: No, that doesn't make sense in C++.
Libraries (dynamic or otherwise) are only used during linking. During compilation declarations must be visible to the compiler in source-code form. This is why, for example, you have to explicitly #include standard library headers in addition to linking against the standard library.
2: What you're already doing is basically the only solution. Put the common header files in their own directory, and add that directory to the include path of each of the two projects.
Can a header file with only class
declaration be compiled into a DLL
No, headers typically include only declarations. Declarations when compiled don't produce any machine code, so resulting DLL would be empty.
For the above scenario, is there a
better approach to reuse the common
Header file among projects?
Reusing header is fine. In fact, every library has it's set of headers that you need to include in projects using that library.
I don't know much Visual C++, but I think you could make third project, containing common parts (i.e. RunAlgo.h header), and mark it as a dependency for AlgorithmA and AlgorithmB projects.
To 1.:
No, free-standing header files never end up in a dll. Header files are included in implementation files and that's how they are compiled. Header files are usually distributed along with a dll or library if you want to allow third parties to link against it.
To 2.:
Why don't you declare an abstract base class with the interface for the algorithm and provide two different implementations by defining two subclasses (AlgorithmA and AlgorithmB) deriving from the base class? I don't get why you want to different DLLs.
To 3.:
No, it shouldn't. See point 1.
Use 2 namespaces in C++ to write 2 different implementation with the same header file
namespace ImplementationA
{
}
namespace ImplementationB
{
}
When you want to use 1st implementation
using implementationA;
or
implementationA::function1();
I'm compiling some code that relies on include guards to prevent multiple definitions of objects and functions, but Visual Studio 2008 is giving me link errors that there are multiple definitions. I don't understand why because I've used code very similar to this before and it hasn't caused problems. I must be doing something dumb but I have no idea what it is. I also tried to take out the include guards and use #pragma once, but I get the same link errors. What should I check for?
If they are linker errors, the most likely cause is probably non-inline functions defined in the header.
If you have a non-inline function in a header that is included in more than one source file, it will be defined in each of those source files ("translation units"), thus the function will be defined more than once, hence the multiple definitions error.
If you're getting linker errors... are you sure you're not 1) actually defining a function twice in code or 2) trying to do something silly like #include a source file (as opposed to a header file)?
This can also be caused by using different versions of the cstd lib from other library's linked in. Check under the c++/Code generation section and make sure all your projects are using the same settings.