I'm getting Linking errors about functions already being defined in other .obj files

[RobotJones]

I'm building a console chess application that (so far) has 10 files:

(3 classes)
Move.h, Move.cpp
Piece.h, Piece.cpp
Player.h, Player.cpp

(display module contains functions used for screen output)
Display.h
Display.cpp

(header for any global variables, enums, constants, etc...)
Chess.h

(and finally the location of 'int main()' and all other functions)
Chess.cpp

Here is a breakdown of how all the files are linked together by #include directives. Of course, each header file contains inclusion guards before anything else to prevent it being compiled more than once.

Chess.cpp #includes Chess.h. Also, all three class headers #include Chess.h for the enums it contains. Then, Chess.h #includes Display.h so that Chess.cpp will have access to all those functions for displaying output. Finally, Display.h #includes several files that I didn't write like iostream, vector, time, string, windows, etc...

Is there a reason why my program only compiles when I declare all functions of the Display module in the header file (Display.h) and then define them all in the implementation file (Display.cpp)? When I try to define some of them in the header file (only the ones that are only like one line) then I get errors about those functions already being defined in another .obj file of one of the classes. Can anyone help me with this? Let me know if I need to include some code or something. I didn't know exactly how much info you'd need to help me out. Thanks in advance for your help.

[Mybowlcut]

I think you'll eventually want to put the enums that are relevant to Move, Piece and Player in their respective header files. I learnt from someone here that having lots of code in one place that is needed by different .h files eventually gets very bad... for the reason that when you edit that "master" header with everything in it (in your case Chess.h), everything else that depends on it needs to be re-compiled. For a small project like yours this won't be a problem, but if you start adding more .h files that rely on Chess.h, then your build times will greatly increase. All you need to do to fix this is like I said, move all the information that is relevant to each file to that file... or create another .h file with the information in it. That way, if you edit that newly created .h file, only files that use it will have to re-compile.

Sorry if that's confusing but maybe someone else can clarify if you're interested.

As for your problem.. are you sure all your include guards are correct? Names are spelt correctly, etc.?

I think this would generally cause a "constructors not allowed a return type" error (depending on where you put your constructor in the .cpp files), but are you sure you've got semi-colons at the end of your class declarations?

Maybe you should post one or two files that the error mentions, along with the exact error in code tags.

[RobotJones]

I think you'll eventually want to put the enums that are relevant to Move, Piece and Player in their respective header files.

Do you mean that if both Piece and Player need this enum:


enum Type { PAWN, KNIGHT, BISHOP, ROOK, QUEEN, KING, NO_TYPE };


...that I should actually have it written twice? One in each of their respective header files? I guess that makes sense. I just assumed that would be bad form to have something written twice when it could only have to be written once. But I can see how this would help like you said. The only downside is that if I decide to alter 'Type', I have to now remember to update BOTH locations rather than just the one.


As for your problem.. are you sure all your include guards are correct? Names are spelt correctly, etc.? ...are you sure you've got semi-colons at the end of your class declarations?

I double checked all the syntax and I believe it's up to snuff. I was thinking it might have something to do with one of these two reasons:

1) The placement of the #include directives. I always place any #include directives after the inclusion guards (#ifndef/#define...) and of course before the #endif. Could it ever be necessary to #include a file before the inclusion guard?

2) I read somewhere that anything in the header file is public and anything in the implementation file is private. Could that have something to do with the errors? I have no clue.

My solutions: 1) Just don't define any functions in my header file, declarations only, or 2) move everything from the implementation file over to the header file and just get rid of Display.cpp altogether. I've tried both solutions and they both work. I was just trying to figure out why I was getting those darned errors. Oh well, something for another day I suppose...

Thanks again.

[Mybowlcut]

Do you mean that if both Piece and Player need this enum:


enum Type { PAWN, KNIGHT, BISHOP, ROOK, QUEEN, KING, NO_TYPE };


...that I should actually have it written twice? One in each of their respective header files? I guess that makes sense. I just assumed that would be bad form to have something written twice when it could only have to be written once. But I can see how this would help like you said. The only downside is that if I decide to alter 'Type', I have to now remember to update BOTH locations rather than just the one.No no no no haha. You're right; that is a really bad thing to do. What I meant was either put it in Piece and have Player include Piece or put it in a file called "Types.h" or something. It would make more sense to put it in Piece.h since Type represents the types that Pieces can be.
I double checked all the syntax and I believe it's up to snuff. I was thinking it might have something to do with one of these two reasons:

1) The placement of the #include directives. I always place any #include directives after the inclusion guards (#ifndef/#define...) and of course before the #endif. Could it ever be necessary to #include a file before the inclusion guard?

2) I read somewhere that anything in the header file is public and anything in the implementation file is private. Could that have something to do with the errors? I have no clue.1) Not that I'm aware of. The way you're doing it is completely right. 2) I'm not sure if it has something to do with it, but I am sure it's correct. You'll have to wait for a more experienced poster to come through. :o

My solutions: 1) Just don't define any functions in my header file, declarations only, or 2) move everything from the implementation file over to the header file and just get rid of Display.cpp altogether. I've tried both solutions and they both work. I was just trying to figure out why I was getting those darned errors. Oh well, something for another day I suppose...

Thanks again.That is preferable anyway... It's just neater, consistent and like you said, anything in a header file is public, and no one except the developer of code needs to know implementation details. In this case, you're the only developer most likely, so it's negligible. But if you ever sell your code to clients or work in a team, I presume you'll want to keep function definitions in .cpp files.

However, I have seen open source games that include function definitions in .h files, so if it's what you wanna do, just wait a while until the more knowledgeable guys/girls come on to help you with the error.

:)

[ZuK]

Did I understand your problem ?
You have some short functions that you want to define ( not only declare) in a header.
Just define them inline.

#ifndef HEADER_INCLUDED
#define HEADER_INCLUDED

int one_liner();

inline int one_liner() { return 0;)

#endif
Kurt

[RobotJones]

Did I understand your problem ?
You have some short functions that you want to define ( not only declare) in a header.
Just define them inline.


Not just any ol' function -- Private class methods. And I might have misunderstood this but I was under the impression that by putting a class method's definition inside the class declaration it would automatically make it inline, even without the use of the keyword 'inline'.

[ZuK]

That's right.
Post some code that shows the problem.
Kurt

[RobotJones]

Actually, I'm an idiot! I just answered the last question incorrectly. These are NOT class methods that I'm trying to define. They are just plain ol' functions. I was confusing this with another problem I was having with class methods. I think I've solved my own problem now. Sorry for the inconvenience! And thanks for the help.

[Paul McKenzie]

I'm building a console chess application that (so far) has 10 files:

(3 classes)
Move.h, Move.cpp
Piece.h, Piece.cpp
Player.h, Player.cpp

(display module contains functions used for screen output)
Display.h
Display.cpp

(header for any global variables, enums, constants, etc...)
Chess.h

(and finally the location of 'int main()' and all other functions)
Chess.cpp

Here is a breakdown of how all the files are linked together by #include directives.We need to see the code, not an explanation of what you think you did correct (or incorrect).

Many times, people post a description of what they did, then after a page or two of back and forth suggestions, we finally see the code. Almost instantaneously, the problem is diagnosed and solved once the actual code is shown, with many times, the code revealed that the original poster did not do what they claimed they did.

Regards,

Paul McKenzie