I recently ran into the problem described in Weird undefined symbols of static constants inside a struct/class and I am trying to bring my code into compliance by adding definitions to the corresponding .cpp files for all of my static const class members, not just the ones that were causing linker errors.
In the cases where the constant is used in multiple compilation units, I am getting multiple definition errors, even though the definition is only in one of the compliation units.
Moving the initializers to the definitions prevent the errors, but I would rather not do that.
For what it's worth, while I am currently working in Visual Studio, this code needs to build on several platforms.
Static member variables are declared in the class body and defined once outside the class body. The general way of doing this is:
class MyClass
{
static int i;
};
int MyClass::i = 0;
The definition is done in the C++ source files and not in header(.h). If it is done so, the variable will defined everywhere the header file being included. It seems you are facing this very same problem.
If you have language extensions enabled, Visual Studio will allow you to use static const objects without defining the in an implementation file. Unfortunately, it will issue an error (if I remember correctly) for correct C++ programs, when there is an explicit definition.
Try to disable language extensions.
According to one of the posts on http://bytes.com/topic/c/answers/710704-const-static-initialization-visual-studio this may actually be a visual studio bug, preventing you from using that form of initialization.
Unfortunately I think you may be stuck doing the initialization in the source file to maintain portability.
I created a simple example that compiled and linked fine in g++ 4.2.
I think if you want your code to work on multiple platforms, you should move the initialisation to the definition (in the .cpp file). While it might work otherwise on one or more compilers, don't rely on it to be portable.
Related
I'm working on a nontrivial parser in C++ on top of boost::spirit::x3. I am splitting up my parsing code into logical units some of which are dependencies of each other. For example, one unit is an expression parser that also exposes an indentifier parser. Many higher level syntactic constructs of the target language include expressions and identifiers so this unit is frequently a dependency. I have split the code into triples of files as the documentation recommends. If there are units foo, bar, and quux, I have files like:
parser
foo.h
foo_def.h
foo.cpp
bar.h
bar_def.h
bar.cpp
quux.h
quux_def.h
quux.cpp
where the .h expands BOOST_SPIRIT_DECLARE; the _def.h expands BOOST_SPIRIT_DEFINE, and the .cpp expands BOOST_SPIRIT_INSTANTIATE. I have run into a persistent problem in which my code errors out at startup due to static initialization fiasco in Spirit code (line 160 of .../x3/nonterminal/rule.hpp) but only when running a debug build.
Based on stackoverflow questions and answers like this one and this one plus the fact that the code executes without error when built in the release configuration, I believe there is nothing wrong with my code. I can see two workarounds if there is no way to fix my code in debug:
Only in debug builds use a pragma declaration to change the order of static initialization. (Changing the order of the items in the .vcxproj file did not affect the initialization order) In Visual Studio if I put a #pragma init_seg(lib) in the .cpp file of my expression parser the problem goes away.
Only in debug builds include superfluous _def.h files where necessary e.g. if quux depends on bar above then including bar_def.h in quux.cpp will fix the problem, but defeats the purpose of splitting the parser into multiple files.
I am wondering generally what the state of this problem is? It seems to be a known issue but has been around a long time and so I should not expect it to be fixed at the Spirit level? Is there some better way to structure my code such that this problem does not occur? I was wondering if it would be possible to, for example, create all parsers and their child parsers as static variables in function scope created on first use but there is no examples like this in the literature so I am unsure if it is possible?
The usual way is to have functions returning local statics by reference.
Function-local statics
have static "lifetime" (storage duration) but will only be initialized on first use (dodging the fiasco)
since C++11 you can even rely on initialization to be thread-safe
So, you might have in the header:
my_rule_type const& my_rule();
And in the cpp that defines the rule:
my_rule_type const& my_rule() {
static const my_rule_type s_my_rule = ns::my_rule;
return s_my_rule;
}
UPDATE
Actually the documentation example doesn't bother with returning references, instead returning a copy each time:
parser::employee_type employee()
{
return parser::employee;
}
This suggests that there won't be significant overhead in doing so, and I recommend you avoid the complication of reference-semantics there.
I'm trying to use a third party C++ library that isn't using namespaces and is causing symbol conflicts. The conflicting symbols are for classes my code isn't utilizing, so I was considering creating custom header files for the third party library where the class declarations only include the public members my code is using, leaving out any members that use the conflicting classes. Basically creating an interface.
I have three questions:
If the compilation to .obj files works, will this technique still cause symbol conflicts when I get to linking?
If that isn't a problem, will the varying class declarations cause problems when linking? For example, does the linker verify that the declaration of a class used by each .obj file has the same number of members?
If neither of those are a problem and I'm able to link the .obj files, will it cause problems when invoking methods? I don't know exactly how C++ works under the hood, but if it uses indexes to point to class methods, and those indexes were different from one .obj file to another, I'm guessing this approach would blow up at runtime.
In theory, you need identical declarations for this to work.
In practice, you will definitely need to make sure your declarations contain:
All the methods you use
All the virtual methods, used or not.
All the data members
You need all these in the right order of declaration too.
You might get away with faking the data members, but would need to make sure you put in stubs that had the same size.
If you do not do all this, you will not get the same object layout and even if a link works it will fail badly and quickly at run-time.
If you do this, it still seems risky to me and as a worst case may appear to work but have odd run time failures.
"if it uses indexes ": To some extent exactly how virtual functions work is implementation defined, but typically it does use an index into a virtual function table.
What you might be able to do is to:
Take the original headers
Keep the full declarations for the classes you use
Stub out the classes and declarations you do not use but are referenced by the ones you do.
Remove all the types not referenced at all.
For explanatory purposes a simplified explaination follows.
c++ allows you to use functions you declare. what you do is putting multiple definitions to a single declaration across multiple translation units. if you expose the class declaration in a header file your compiler sees this in each translation unit, that includes the header file.
Therefore your own class functions have to be defined exactly as they have been declared (same function names same arguments).
if the function is not called you are allowed not to define it, because the compiler doesn't know whether it might be defined in another translation unit.
Compilation causes label creation for each defined function(symbol) in the object code. On the other hand a unresolved label is created for each symbol that is referenced to (a call site, a variable use).
So if you follow this rules you should get to the point where your code compiles but fails to link. The linker is the tool that maps defined symbols from each translation-unit to symbol references.
If the object files that are linked together have multiple definitions to the same functions the linker is unable to create an exact match and therefore fails to link.
In practice you most likely want to provide a library and enjoy using your own classes without bothering what your user might define. In spite of the programmer taking extra care to put things into a namespace two users might still choose the same name for a namespace. This will lead to link failures, because the compiler exposed the symbols and is supposed to link them.
gcc has added an attribute to explicitly mark symbols, that should not be exposed to the linker. (called attribute hidden (see this SO question))
This makes it possible to have multiple definitions of a class with the same name.
In order for this to work across compilation units, you have to make sure class declarations are not exposed in an interface header as it could cause multiple unmatching declarations.
I recommend using a wrapper to encapsulate the third party library.
Wrapper.h
#ifndef WRAPPER_H_
#define WRAPPER_H_
#include <memory>
class third_party;
class Wrapper
{
public:
void wrappedFunction();
Wrapper();
private:
// A better choice would be a unique_ptr but g++ and clang++ failed to
// compile due to "incomplete type" which is the whole point
std::shared_ptr<third_party> wrapped;
};
#endif
Wrapper.cpp
#include "Wrapper.h"
#include <third_party.h>
void Wrapper::wrappedFunction()
{
wrapped->command();
}
Wrapper::Wrapper():wrapped{std::make_shared<third_party>()}
{
}
The reason why a unique_ptr doesn't work is explained here: std::unique_ptr with an incomplete type won't compile
You can move the entire library into a namespace by using a clever trick to do with imports. All the import directive does is copy the relevant code into the current "translation unit" (a fancy name for the current code). You can take advantage of this as so
I've borrowed heavily from another answer by user JohnB which was later deleted by him.
// my_thirdparty.h
namespace ThirdParty {
#include "thirdparty.h"
//... Include all the headers here that you need to use for thirdparty.
}
// my_thirdparty.cpp / .cc
namespace ThirdParty {
#include "thirdparty.cpp"
//... Put all .cpp files in here that are currently in your project
}
Finally, remove all the .cpp files in the third party library from your project. Only compile my_thirdparty.cpp.
Warning: If you include many library files from the single my_thirdparty.cpp this might introduce compiler issues due to interaction between the individual .cpp files. Things such as include namespace or bad define / include directives can cause this. Either resolve or create multiple my_thirdparty.cpp files, splitting the library between them.
We have attempted to reduce code duplication through the use of the TEST_GROUP_BASE to create a shared base class. When we attempt to use this TEST_GROUP_BASE in more than one test class, we get linker warnings complaining about 'getwchar'and 'putwchar': inconsistent dll linkage and errors reporting multiple definitions of both these functions, and a number of other 'char'/'wchar' pairs (e.g. strchr/wcschr, strpbrk/wcspbrk). If I only include one test file that makes use of the TEST_GROUP_BASE macro, the linker errors don't appear.
The base class is defined as a TEST_BASE in a .h file with all the member functions inlined. This .h file is then included in the derived test files with the TEST_GROUP_BASE macro used to incorporate the shared TEST_BASE. Have I missed anything?
I've not managed to find any examples of TEST_GROUP_BASE being used so I'm not sure whether I've missed a critical piece of configuration. We are testing legacy C code, but all references to the production code are made within extern "C" braces, since our simple tests pass that would suggest that the c/c++ is linking OK.
Can anyone suggest any possible causes, or point me in the direction of any opensource examples of how TEST_GROUP_BASE is being used elsewhere?
The development environment is VS2010.
I'm not quite sure why there are errors on putwchar and getwchar, that probably is unrelated to TEST_BASE AND TEST_GROUP_BASE but probably relates to them being inline and the header file being included with different linkage. Without a code example, it would be hard to figure out where the different linkage problems come from, especially as you mentioned that it works with only one TEST_GROUP_BASE.
Probably the best way to resolve this problem though is to not put all the TEST_BASE functions inline in the header file. The TEST_BASE macro is actually very simple replacement for "struct testBaseClass : public Utest". So a TEST_BASE is simply any class that is sub-classed from Utest. That means that you can simply put the implementation in a cpp file.
One of the reasons why you can't find much usage of TEST_GROUP_BASE is that many people (including me) recommend against using it. It is often more flexible to put the parts that you want to re-use in a seperate class and use (rather than derive) that class in your TEST_GROUP. This allows for many smaller "fixture" classes that can be re-used across different tests.
Hope this helps.
Many C++ projects (e.g. many Boost libraries) are "header-only linked".
Is this possible also in plain C? How to put the source code into headers? Are there any sites about it?
Executive summary: You can, but you shouldn't.
C and C++ code is preprocessed before it's compiled: all headers are "pasted" into the source files that include them, recursively. If you define a function in a header and it is included by two C files, you will end up with two copies in each object file (One Definition Rule violation).
You can create "header-only" C libraries if all your functions are marked as static, that is, not visible outside the translation unit. But it also means you will get a copy of all the static functions in each translation unit that includes the header file.
It is a bit different in C++: inline functions are not static, symbols emitted by the compiler are still visible by the linker, but the linker can discard duplicates, rather than giving up ("weak" symbols).
It's not idiomatic to write C code in the headers, unless it's based on macros (e.g. queue(3)). In C++, the main reason to keep code in the headers are templates, which may result in code instantiation for different template parameters, which is not applicable to C.
You do not link headers.
In C++ it's slightly easier to write code that's already better-off in headers than in separately-compiled modules because templates require it. 1
But you can also use the inline keyword for functions, which exists in C as well as C++. 2
// Won't cause redefinition link errors, because of 6.7.4/5
inline void foo(void) {
// ...
}
[c99: 6.7.4/5:] A function declared with an inline function
specifier is an inline function. The function specifier may appear
more than once; the behavior is the same as if it appeared only once.
Making a function an inline function suggests that calls to the
function be as fast as possible. The extent to which such
suggestions are effective is implementation-defined.
You're a bit stuck when it comes to data objects, though.
1 - Sort of.
2 - C99 for sure. C89/C90 I'd have to check.
Boost makes heavy use templates and template meta-programming which you cannot emulate (all that easily) in C.
But you can of course cheat by having declarations and code in C headers which you #include but that is not the same thing. I'd say "When in Rome..." and program C as per C conventions with libraries.
Yes, it is quite possible. Declare all functions in headers and either all as static or just use a single compilation unit (i.e. only a single c file) in your projects.
As a personal anecdote, I know quite a number of physicists who insist that this technique is the only true way to program C. It is beneficial because it's the poor man's version of -fwhole-program, i.e. makes optimizations based on the knowledge of function behaviour possible. It is practical because you don't need to learn about using the linker flags. It is a bad idea because your whole program must be compiled as a whole and recompiled with each minor change.
Personally, I'd recommend to let it be or at least go with static for only a few functions.
I'm using static initialisation to ease the process of registering some classes with a factory in C++. Unfortunately, I think the compiler is optimising out the 'unused' objects which are meant to do the useful work in their constructors. Is there any way to tell the compiler not to optimise out a global variable?
class SomeClass {
public:
SomeClass() {
/* do something useful */
}
};
SomeClass instance;
My breakpoint in SomeClass's constructor doesn't get hit. In my actual code, SomeClass is in a header file and instance is in a source file, more or less alone.
EDIT: As guessed by KJAWolf, this code is actually compiled into a static lib, not the executable. Its purpose is to register some types also provided by the static lib with a static list of types and their creators, for a factory to then read from on construction. Since these types are provided with the lib, adding this code to the executable is undesirable.
Also I discovered that by moving the code to another source file that contains other existing code, it works fine. It seems that having a file purely consisting of these global objects is what's causing the problem. It's as if that translation unit was entirely ignored.
The compiler is not allowed to optimiza away global objects.
Even if they are never used.
Somthing else is happening in your code.
Now if you built a static library with your global object and that global object is not referenced from the executable it will not be pulled into the executable by the linker.
The compiler should never optimize away such globals - if it does that, it is simply broken.
You can force that one object (your list of types) pulls some other objects with it by partially linking them before building the complete static lib.
With GNU linker:
ld -Ur -o TypeBundle.o type1.o type2.o type3.o static_list.o
ld -static -o MyStaticLib.a type_bundle.o other_object.o another_object.o ...
Thus, whenever the static list is referenced by code using the library, the complete "TypeBundle.o" object will get linked into the resulting binary, including type1.o, type2.o, and type3.o.
While at it, do check out the meaning of "-Ur" in the manual.
To build off of Arthur Ulfeldt, volatile tells the compiler that this variable can change outside of the knowledge of the compiler. I've used it for put a statement to allow the debugger to set a breakpoint. It's also useful for hardware registers that can change based on the environment or that need a special sequence. i.e. Serial Port receive register and certain watchdog registers.
you could use
#pragma optimize off
int globalVar
#pragma optimize on
but I dunno if that only works in Visual Studio ( http://msdn.microsoft.com/en-us/library/chh3fb0k(VS.80).aspx ).
You could also tell the compiler to not optimize at all, especially if you're debugging...
Are you using gcc with gdb? There was a problem in the past where gdb could not accurately set breakpoints in constructors.
Also, are you using an optimization level which allows the compiler to inline methods in the class definition.
You need to use -whole-archive when linking. See the answer here:
ld linker question: the --whole-archive option
I have same setup & problem on VS2008.
I found that if you declare you class with dllexport it will not optimize.
class __declspec( dllexport ) Cxxx
{
.
}
However this generates a lot of warnings in my case because I must declare all classes used in this class also as dllexport.
All optimizations are off (in debug mode), still this is optimized. Also volatile/pragma optimize off. On global variable created of this class (in same cpp file) etc does not work.
Just found that dllexport does require at least to include header files of these classes in some other cpp file from exe to work! So only option is to add a file with calls to some static members for each class, and add this file to all projects used these classes.
It would not be a compiler, but the library linker (or the tool that pools object files into the .lib), who can decide that the whole file is not used, so discard it.
A workaround would be to add an empty function to that file and call it from a file that contains stuff that is called directly.
How about using the keyword volatile? It will prevent the compiler from too much optimization.