Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

shalom

Linking errors

This topic is 6110 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have never written large programs in C++ before, so I''m having trouble getting used to keeping programs in several files. I''m having a weird linking error. I defined a class in one file. I am including this file in the main file. I am getting the following linking error: MyFileName.obj : error LNK2005: "public: __thiscall MyClassName::MyClassName(MyArgumentList)" (??0MyClassName@@QAE@PAUHINSTANCE__@@PAUHWND__@@@Z) already defined in Input.obj This is obviously for my constructor (MyClassName::MyClassName). It comes up with similar messages for my other member functions. Then, it comes up with: Debug/MyFileName.exe : fatal error LNK1169: one or more multiply defined symbols found It seems that I am defining my classes functions more than once, but I''m not. For some reason, I got it to work the first couple of times using strange methods. I commented out all of the code (determined to find out the problem) of the class, and since it wasn''t called anywhere, it compiled and ran fine. Then, when I uncommented it, it still worked. However, when I did a major change such as add a function or something, it came up with the same errors and I had to do it again. Not only did this become a hassle (having to comment out all calls the the class, too), it also seems rediculous and odd. I feel like this is some dumb problem, but I guess I''m dumb and please help me. Thank you. In my thunking device, what happens to the inherited pointer to the original base class when I override the function & how do I access it in my inline assembly code, assuming that we are referencing the higher byte of the 16-bit variable?

Share this post


Link to post
Share on other sites
Advertisement
Without seeing the code, I can only give you a few pointers (haha get it? pointers! ok nevermind ) -

1. Always use multiple inclusion protection in your header files.

2. Don''t put implementation into header files (unless it''s a small function within the definition itself; then it''s ok).

I can elaborate if you need, but I have a broken wrist and am stuck typing with one hand

Share this post


Link to post
Share on other sites
I haven''t protected against double declaration, but its a small enough program to tell that no headers are doubly included. What''s the problem with having function definitions in headers? Is one supposed to put all implementation into one file?

In my thunking device, what happens to the inherited pointer to the original base class when I override the function & how do I access it in my inline assembly code, assuming that we are referencing the higher byte of the 16-bit variable?

Share this post


Link to post
Share on other sites
Im not to experienced with this but everytime I see source code that a h file declares a class they have always made a cpp file that has the implemation.

Jeff D



Suffered seven plagues, but refused to let the slaves go free. ~ Ross Atherton

Share this post


Link to post
Share on other sites
Aiiight. Here''s the gist.

In your header file...

  
#ifndef __MYCLASSNAME

#define __MYCLASSNAME


/*put your class DECLARATION here.*/

#endif


In your cpp file....

  
#include "classname.h" //or whatever


/* put your class IMPLEMENTATION (definition) here.*/



In your main cpp file...

  
#include "classname.h"

MyClassName ThisIsAnInstance
...



That wasn''t too clear. I think that should explain it, but if you need more, just ask.

Later,
ZE.

Share this post


Link to post
Share on other sites
I''ll try that out, but I''m just curious as to why that works. How does the .cpp file get included? I''ll also put in the #ifdef stuff for safety - even though I''m sure I''m not doubly including anything now, it''ll be useful when (if) it gets bigger.

Share this post


Link to post
Share on other sites
ZealousElixir''s example is absolutely correct, doing it any other way is just asking for trouble.

The .cpp gets included as long as it shares the same name as the .h file - it''s how the compiler works (through the makefile).

As for multiple inclusion protection of header is concerned, it''s good idea to put that in even if it''s for a tiny program because
1) You''ll never know if someday down the road you''ll want to expand that header file into a bigger project
2) It a good habit to have. It prevents some silly errors that may take any programmers days to find if s/he is not thinking about it.

Share this post


Link to post
Share on other sites
If you use a relatively new compiler, such as VC++, or anything that has an windows interface, you can usually add the .cpp file to the project. Then it will automatically compile it and link it in.
If you have an dos based, commandline compiler, then you should get an makefile system. Or, you can do this (let''s assume you went and downloaded the free borland compiler):
bcc32 mainfile.cpp classimp.cpp
The whole point of makefiles is to automate stuff like that... it gets tedious once you have around 10 files...
but that''s getting off topic.

Share this post


Link to post
Share on other sites
As a touch of clarification, whenever a cpp file is included in your project (in MSVC, as you are), it will be compiled and linked, unless you use the file settings to exclude it from the build.

Hope that helps,
ZE.

Share this post


Link to post
Share on other sites
Thanks, I finally got around to trying it and it worked

In my thunking device, what happens to the inherited pointer to the original base class when I override the function & how do I access it in my inline assembly code, assuming that we are referencing the higher byte of the 16-bit variable?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!