Symbol already defined problem
Brought to you by:
blep
Menu
▾
▴
Hi all.
I just started using cppunit a couple of weeks ago. Last night, I went through an interesting problem, which I don`t know for sure wether has anything to do with cppunit. That`s why I`m posting it here.
I`m building a big library (under MCVS .NET using precompiled headers).
I have a class Planarity, defined in Planarity.h.
The class is NOT template, however it has few template member functions. All member functions of Planarity are also defined in Planarity.h after the class declaration/definition.
I have sample application that references the project in which Planarity is defined. The main() of this application uses Planarity and everything compile and build fine.
Last night, I started writting code to test Planarity. So, I created class TestPlanarity (and naturally included '#include <Planarity.h>' in TestPlanarity. For my surprise, my project didn`t build (I also have test for other classes in my project using cppunit). I was prompted by a link error of 'symbol already defined' for ALL member functions of Planarity that are not template. The symbols were already defined in 'TestGraphStuff.obj', which is another cppunit test class, that also includes 'Planarity.h'.
So it means that on the 'second' cppunit test class I included 'Planarity.h', I got the error.
WEIRD THINGS:
I have 'include guardians' for all my files.
I have other files that ALSO include 'Planarity.h' and all of them compile/build fine.
I only had the problem when I included 'Planarity.h' from 2 cppunit test classes (as I said, I got the error when creating the second class that had a include 'Planarity.h').
SOLUTION:
Then after that, I decided to implement all NON template member functions of Planarity in a new file Planarity.CPP (I created Planarity.cpp for this purpose). I tried to build everything and everything compiled/built fine.
I also tried removing Planarity.cpp and implement all the NON template member functions of planarity inside the class declaration/defintion (instead of AFTER the class declaration/definition, as I had before). This way, everything also compiled/built fine.
QUESTION:
This is all weird. I don`t think it`s a pure 'c++' issue, because as I said I have other files that use Planarity and they compile/build fine. That`s why I ask here wether this could have something to do with cppunit.
I`d appreciate any comment.
Thanks.
Actually, this IS a "pure C++" problem, as you call it. It sounds like you need to understand the difference between a declaration and a definition. In C++ you can DECLARE variables, functions, classes, etc. as many times as you wish throughout the files that will be built into the final executable. However, you can only DEFINE each thing once.
If you need any help understanding this, please feel free to contact me via email.
p.s. it is a common convention to only put declarations in a header (.h) file and definitions in a .cpp file. The primary exceptions to this rule are definitions for template classes and methods and definitions for inline methods.
Hi Layne.
I understand differences among declarations, definitions and header (.h) and implementation (.cpp) stuff.
I'm not an experienced c++ programmer, however I'm not also a beginner.
I'm very used to this kind of errors. However, this one really made confused because my whole application uses that class (and calls the include directive). And only when I included it from the cppunit, I got the error telling that the class was already defined in one other test class (also from cppunit). So, I thought those cppunit macros could be doing some weird stuff (I didn't look up at the macros, so it was just a guess).
But anyway, I'm propably missing something here...
I'll write you a private e-mail later.
Thanks.
In your application, do you #include this header in multiple .cpp files that are later linked to make the project? Or do you only #include it once?
The other possibility is that even though you #include the .h file in multiple .cpp files, if you never don't actually call functions from the header file, the linker might not complain about it. This depends a lot on which compiler you are using. And it also dependds on knowing how the compiling and linking stages interact. I primarily program in Java these days, so it's been a while since I have dealt with such issues.