vector is included in only one source file. The only stl include in the header files is string. Yet I cannot get rid of multiple definition errors (example below). Any ideas?
./plugin_dfb.o:mipsel-linux-uclibc/include/c++/4.2.0/bits/stl_bvector.h:182: multiple definition of `std::operator-(std::_Bit_iterator_base const&, std::_Bit_iterator_base const&)'
./painter.o:mipsel-linux-uclibc/include/c++/4.2.0/bits/stl_bvector.h:182: first defined here
This std::operator- is an inline function with external linkage. It appears the linker doesn't support multiple definitions of such inline functions. But the "one definition rule" of C++ (ODR) clearly allows this. Typically such symbols get "weak linkage" (GNU terminology) but I think both, the object file format and the linker, need to support this.
I would try to ask a question in a group / mailing list dedicated to your platform. Something along the lines of "Does platform X support C++ with respect to linking and the C++-related one-definition rule for inline functions and templates?".
You may also want to check the GCC documentation. It's possible that they provide a command line switch as a work-around. If you don't already use g++ as front-end to the linker, you should try it. Maybe that helps, too.
have you tried using #pragma once?
I think you have included the vector in only one header file but that header file is not having the #define block, this is resulting the redefinition of the vector header file included in it.
Please enclose your include file in the template given below and try.
#if !defined(HEADER_FILE)
#define HEADER_FILE
// Your code
#endif
As the problem appears during linking it looks to be related to template instantiation. Given instantiation implementation specifics the template functions/definitions should be put in the common include files to assure they are visible everywhere and do not duplicate header includes what may be the case here.
From what you posted problem concerns the operator - that may be used by std::distance() that may be called from find() type functions. So look if you have such functions defined or called as they may work with vectors and strings and make sure they are in shared header files.
Related
I'm working my way through a C++ tutorial, and in one of the articles on the preprocessor/header files the author creates 2 'header files' (not the technical term, of course), example.h and example.cpp. In example.h he puts the forward declarations for the functions and the header guard, and in example.cpp the actual body of the functions. Why is this? I tried putting the body of the function in the example.h file and it worked just fine, so why does he put it separately? Is it customary, or does it pose problems in bigger problems? Or what?
Can someone please enlighten me on this...
C++ has a rule called the one-definition rule that says that every function needs to be defined once and only once (there are a few exceptions to this rule, but we'll ignore them for now.) The function prototype typically included in a header file is a declaration saying that the function exists, and the implementation in the .cpp file is the definition giving the code for the function.
If you put the definition of the function in a header file and then include the header file in multiple places, you'll get linker errors because you're breaking the one definition rule - each .cpp file that's compiled will have its own copy of the definition of the function. On the other hand, if you just put the declaration in the header and then put the definition in a single source file, then there's only one definition and nothing will break.
There are a few exceptions for the one definition rule. First, all inline functions are exempt from ODR, so you could potentially put function definitions in a header file if you mark all the functions inline, though this is generally not considered a good idea for all but the smallest functions. Second, template functions are exempt from the ODR, which (among other things) is one of the reasons you see template functions defined in headers.
Put the function body in example.h. Then, when you write a second .cpp file that also includes example.h, and link it with example.cpp, then you'll get a linker error. The linker will see 2 definitions of the function in example.h.
Becouse in the header file you only declare functions that is really important when you want to use a custom linking configuration. For example if a function is defined in a file object and is used in an another object the linker must have the same reference for this function to link the two different files.
Let's assume I have 3 cpp-files:
Main.cpp
First.cpp
Second.cpp
Now i want to use functions from First and Second in Main. Is there something to complain about, if I used only one header-file for both cpp-files and their functions?
Could there be any problems, when using the header-file in First, because I need a Function from Second in First?
As long as you follow the ODR - One Definition Rule and every declaration is consistent, you will be fine.
Headers are usually meant to provide declarations for functions and other stuff, the linking phase (except when there's something a bit more involved like templates) will take care of resolving those dependencies.
I'm not saying anything on the design - not enough info provided.
One header, Several Cpps.
All Functions in Cpps can be declared in one header file. (Ex: "general.h")
And All Cpps should include the "general.h" file.
Then define bodies of declared functions.
No, as long as you provide exactly one definition for each declaration to the compiler, it will be fine.
However it is a best practice to provide one source file per header file : if "First" need both, you just include First.h and Second.h
As far as C++ goes, there won't be any issues with using one header file and splitting the actual implementations of the functions between 2 files. However this strays from convention, if you need functions from "Second.cpp" in "First.cpp" perhaps you should look at what is happening in each one and maybe the functionality should be separated into another file.
As personal preference I say you should stick to having one cpp file for each header file. Splitting the implementation is just going to cause headaches later if you need to refactor or move the implementation again.
Just chiming in to say if you're using an architecture where you're mixing server and client code in one definition, have them separated by different cpp files may be the way to go.
I know people recommend including header guards in header files, to prevent header files contents from being inserted by the pre-processor into the source-code files more than once.
But consider the following scenario:
Let's say I have the files main.cpp , stuff.cpp, and commonheader.h, with the .h file having its header guards.
If either .cpp files tries to include commonheader.h more than once, then the preprocessor
will stop that from happening, and after compiling to object code we get,
main.o containing the contents of commonheader.h exactly once.
stuff.o containing the contents of commonheader.h exactly once.
Note that the contents of commonheader, have been repeated across the files, but not within the same .o file.
So what happens during the linking step? Since the .o files are being fused into an exectuable
we will have to ensure for a second time that the contents of commonheader are not being repeated. Does the compiler take care of that? If not, wouldn't that be a problem when we are dealing with huge header files, giving rise to code repetition across files and leading to large executable sizes.
If I am making some conceptual mistake anywhere in the question, please correct me.
Typically your header file should not actually define any symbols, it should just declare them. So commonheader.h would look like this (omitting the include guards):
void commonFunc1(void);
void commonFunc2(void);
In that case, there is no problem. If you call commonFunc1 in main.cpp and stuff.cpp, both main.o and stuff.o will know they want to link against a symbol called commonFunc1 and the linker will try to find that symbol. If the linker doesn't find the symbol, you get an undefined reference error. The actual definition of commonFunc1 needs to be in some cpp file.
If you really want to define functions in your header file, use static so that the linker does not see them. So your commonheader.h could look like:
static void commonFunc1()
{
/* ... do stuff ... */
}
In this case, the linker does not know about commonFunc1 and no errors will occur. This could increase the executable size though; you'll probably end up with two copies of the code for commonFunc1.
To expand Grayson's answer to cover variables. If you want to declare a variable in a header file you should use the extern keyword. This is one way to handle global variables.
In the header file global.h you write this:
extern Globals globals;
then you can use foo in any file including global.h, while in global.cpp you write
#include "globalstype.h"
Globals globals;
Note that global.cpp doesn't need to include global.h, however you will need to make sure global.cpp is compiled into each usage otherwise the linker will complain.
Header files normally contain declarative code not definitive code. That is they declare the existence of something that must exist exactly once. Macros and inline functions are allowed and necessarily duplicate wherever they are used.
The declarations are used by the compiler to insert unresolved links (or references) into the object code. The job of the linker is to resolve these links by matching the reference with the one single definition.
If you omit the include guards, with multiple inclusion in a single translation unit you will get a compiler error for multiple declaration of an existing symbol. If however you have a header erroneously containing a definition, and the header is included in more than one translation unit, there will be more than one object file with a definition - this instead causes a linker error for multiple definition.
So while:
extern int b ; // declaration, may occur in multiple translation units
is fin in a header file,
int b ; // definition, must occur in only object file.
is not.
Not the the declarations are not included in the object code, rather the compiler uses them to create references that the linker will resolve if the compiler has not already uses the definition and resolved it already.
Yes, it can be a problem. You could end up with multiple definitions, or redundant copies.
C is quite simple in this regard. You have static, extern, and inline -- and compilers also define several ways to alter visibility. I think a lot of this has been covered by other answers.
C++ is quite different, however. There is a lot of information and there are also implicit definitions (e.g. the compiler may emit a copy constructor or RTTI).
With C++, the likelihood that a definition appears in a header is much more likely -- consider templates, methods defined in a class declaration, and so on. C++ defaults to using the One Definition Rule. You will want to read about it in more detail, but it basically states that some categories of symbols may be multiply-defined; depending on the decoration and the location/scope of declaration, that in many cases, the linker is allowed to assume that each body (definition) is identical and it is free to discard any copies it encounters (leaving one definition in your binary). So this really cuts down on the size of the resulting binary, unless you specify a copy shall be produced.
However, having those definitions in your headers can surely increase compilation times, memory and files required to compile each file, visible dependencies, and will increase the number of files which must be recompiled when a definition is edited.
Of course, the language still allows bad forms, and will not complain if you repeatedly state over and over again and include in multiple translations definitions which must be copied for each translation. Then you can certainly end up with a lot of bloat.
This may be a good intro:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=386
I'm working on a very tiny piece of C/C++ source code. The program reads input values from stdin, processes them with an algorithm and writes the results to stdout.
I would just implement all that in a single file, but I also want test cases for the algorithm (not the input/output reading), so I have the following files in my project:
main.cpp
sort.hpp
sort_test.cpp
I implement the algorithm in sort.hpp right away, no sort.cpp. It's rather short and doesn't have any dependencies.
Would you say that, in some cases, functions defined in headers are okay, even if they are sophisticated algorithms and not just simple accessors/mutators? Or is there a reason I should avoid this? When should I move code from header to source file?
There is nothing wrong with having functions in header files, as long as you understand the tradeoff. Putting them in a header file means they'll have to be compiled (and recompiled) in any translation unit that includes the header. (and they have to be declared inline, or you will get linker errors.)
In projects with many translation units, that may add up to a noticeable slowdown in compile times, if you do it a lot.
On the other hand, it ensures that the function definition is visible everywhere the function is called -- and that means that it can be trivially inlined, so the resulting program may run faster.
And finally, with function templates, you typically have no realistic alternative. The definition must be visible at the call site, and the only practical way to achieve that is to put it in a header.
A final consideration is that header-only libraries are easier to deploy and use. You don't need to link against anything, you don't have to worry about ABI's or anything else. You just add the headers to your project, include them and off you go.
Quite a few popular libraries use a header-only strategy.
When you put functions in headers you have to make sure to declare them inline. This is required to avoid a duplicate definition warning when more than one .cpp file include that header file. Generally you should only put small functions inside header files because it will be compiled for each cpp file that includes the header which will slow down compilation time and also results in code bloat; a larger executable file.
It's OK to put any function in the header as long as it's inline. Things such as functions defined inside class { } and templates are implicitly inline.
If the resulting application becomes too large, then optimize the code size. Optimizing before there is a problem is an anti-pattern, especially when there is a benefit to doing it "your way," and the fix is as simple as moving from one file to another and erasing inline.
Of course, if you want to distribute the code as a library, then deciding between a header, static library, or dynamic library binary is an important decision affecting the users.
The vast majority of the boost libraries are header-only, so I'd say: Yes, this is an established and accepted practice. Just don't forget to inline.
That really is a stile choice. But putting it in the header does mean that it will be inline code rather than a function. If you wanted that same functionality, you could use the inline keyword:
inline int max(int a, int b)
{
return (a > b) ? a : b;
}
http://en.wikipedia.org/wiki/Inline_function
The reason you should avoid this in general (for non inline functions) is because multiple source files will be including your header, creating linker errors.
It doesn't matter if you have a pramga once or similar trick - the duplication will show up if you have more than one compilation unit (e.g. cpp files) including the same header.
If you wish to inline the function, it MUST be in the header else it can't get inlined.
If you publish a header with your libraries and the header has some sort of implementation in it, you can be sure that after a few years if you change the implementation and it doesn't work exactly the same way as it did before, some peoples code will break since thay will have come to rely on the implementation they saw in the header. Yeah i know one should not do it but many people do look in header for the implementation and other behaviour they can exploit/use in a not intended way to overcome some problem they are having.
If you are planning to use templates then you have no choice but to put it all in header. (this might not be necessary if you compiler supports export templates but there is only 1 i know of).
Its ok to have the implementation in the header. It depends on what you need. If you separate the definition to a different file then the compiler will create symbols with external linkage if you dont want that you can define the functions inside the header itself. But you would be wasting some amount of memory for the code segment. If you include this header file in two different files then both files codes segment will have this function definition.
If other header file is going to have a function with similar name then its going to be a problem. Then you have to use inline.
When writing a header library (like Boost), can one define free-floating (non-method) functions without (1) bloating the generated binary and (2) incurring "unused" warnings?
When I define a function in a header that's included by multiple source files which in turn is linked into the same binary, the linker complains about redefinitions. One way around this is to make the functions static, but this reproduces the code in each translation unit (BTW, can linkers safely dereplicate these?). Furthermore, this triggers compiler warnings about the function being unused.
I was trying to look for an example of a free-floating function in Boost, but I couldn't find one. Is the trick to contain everything in a class (or template)?
If you really want to define the function (as opposed to declaring it), you'll need to use inline to prevent linker errors.
Otherwise, you can declare the function in the header file and provide its implementation separately in your source file.
You can use the inline keyword:
inline void wont_give_linker_errors(void)
{
// ...
}
Er... The answer to your question is simply don't. You just don't define functions in header files, unless they are inline.
'static' function can also be defined in headers, but it is only useful for very specific rare purposes. Using 'static' just to work around a multiple-definition problem is utter nonsense.
Again, header files are for non-defining function declarations. Why on Earth would you want to define functions there?
You said you are writing "header library". What's a "header library"? Please note, that Boost defines its "functions" in header files because their "functions" are not really functions, they are function templates. Function templates have to be defined in header files (well, almost). If that's wasn't the case, Boost wouldn't be doing something as strange as defining anything in header files.
Besides the already mentioned inline, with most compilers templates have to be defined in headers (and with all compilers it's allowed). Since boost is mostly templates, that explains why it is almost all headers.
People have suggested inline but that violates the very first part of your question i.e. it bloats the code as the full definition is inserted into the code at each call of the function. The answer to your overall question is therefore "No".
If you mark them as static then they are still defined in each source file as you rightly pointed out but only once and so that's a better option than inline if code size is the only issue. I don't know if linkers can, or are allowed to, spot the duplicates and merge them. I suspect not.
Edit:
Just to clear up any confusion as to whether I support the notion of using static and/or defining functions within headers files generally then rest assured I don't. This was simply meant as a technical response as to the differences between functions marked inline and static defined in header files. Nothing more.