Elysian Shadows

<SOLVED>
I needed to re-install SFML XD.
Thank you Ginto8 and Nokurn :-D
</SOLVED>

Hello everyone!

Sorry to post such a nooby question, but I have tried everything on this.

First of all I am extremely happy to announce I have completed my game engine after 2 years of hard work
I want to thank every one here for putting up with my stupidity and helping me so much I do not know were
I would be without forums like this one :-D !

Now for the question:
My engine compiles/links fine. However I tried to copy/paste the project and I added a couple game object classes
into the code for a small demo I am making with it for my school science fair. It compiles fine, however I re-opened the
project to add in 4 lines of code and I tried just compiling it first without changing anything and bam the error. For some reason
(I am using SFML 1.6, IDE = VC++ 2008) sf::RenderWindow is declared but not defined. I tried copying the code into another project
I tried deleting the .lnk (link file) manually (several times) I tried cleaning the solution, I tried targeting different versions of SFML
(meaning either the -d version the -s version or the version without anything on the end), and combinations of the 4 and more (and of course standard
debugging techniques); no luck. I have come to find out that it is looking
in (SFML's)image.hpp for the definition of sf::RenderWindow were the only declaration that exists is: It shows all the classic's of a linker error right? <reference> WRONG </reference>!! It shows up in the compiler every time I reference a member of
sf::RenderWindow but of course not when instantiating one. Seeing as I have to replace the entire collision system re-compilation is necessary (the .exe runs fine 0.0).
I have spent about 3 days on this, can someone please help.

Thanks for reading :-D

P.s I know I can sometimes have a hard time getting my point across, please tell me if you need me to re-phrase

-----EDIT-----
I changed the title to more accurately address the issue.

What is the exact message from link.exe/ld/whatever?

Here is an example: http://pastebin.com/xGgm1bup

That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

THe Floating Brain wrote:

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

I'm kind of worried that you might have included inside of a namespace block, with all of those namespaces. That would prevent it from being included again (because include guards are on the preprocessor level, which doesn't give a damn about namespaces), while hiding the sf::RenderWindow declaration in one of your own namespaces. Check for include directives inside of namespaces anywhere. Try using IntelliSense to probe your own namespaces for a sf namespace. Try running the file through the preprocessor (/E or /P /Fi) and searching for all instances of "class RenderWindow" to see where the file's being included.

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

I'm kind of worried that you might have included inside of a namespace block, with all of those namespaces. That would prevent it from being included again (because include guards are on the preprocessor level, which doesn't give a damn about namespaces), while hiding the sf::RenderWindow declaration in one of your own namespaces. Check for include directives inside of namespaces anywhere. Try using IntelliSense to probe your own namespaces for a sf namespace. Try running the file through the preprocessor (/E or /P /Fi) and searching for all instances of "class RenderWindow" to see where the file's being included.

Thought it might be it, after looking at all instances of #include none were in a namespace Good guess though.

THe Floating Brain wrote:

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

I'm kind of worried that you might have included inside of a namespace block, with all of those namespaces. That would prevent it from being included again (because include guards are on the preprocessor level, which doesn't give a damn about namespaces), while hiding the sf::RenderWindow declaration in one of your own namespaces. Check for include directives inside of namespaces anywhere. Try using IntelliSense to probe your own namespaces for a sf namespace. Try running the file through the preprocessor (/E or /P /Fi) and searching for all instances of "class RenderWindow" to see where the file's being included.

Thought it might be it, after looking at all instances of #include none were in a namespace Good guess though.

Can you post the preprocessor output?

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

I'm kind of worried that you might have included inside of a namespace block, with all of those namespaces. That would prevent it from being included again (because include guards are on the preprocessor level, which doesn't give a damn about namespaces), while hiding the sf::RenderWindow declaration in one of your own namespaces. Check for include directives inside of namespaces anywhere. Try using IntelliSense to probe your own namespaces for a sf namespace. Try running the file through the preprocessor (/E or /P /Fi) and searching for all instances of "class RenderWindow" to see where the file's being included.

Thought it might be it, after looking at all instances of #include none were in a namespace Good guess though.

Can you post the preprocessor output?

Here is the pre-processor output from Lightning Sprite.cpp (were the lines I sent before were from) http://pastebin.com/g2uCstsy
I noticed since when you compile with /P in Visual Studio it doesn't generate the .obj files, that there were no errors (although there were when I disabled /P), I dont know if this is kinda a derp or not

THe Floating Brain wrote:

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:

THe Floating Brain wrote:

Nokurn wrote:That is a compiler error not a linker error. It's happening because the compiler knows sf::RenderWindow is a class, since Image.hpp forward declared it, but you're using it without the compiler knowing the actual body of the class. It has no idea whether or not the class has a Draw method, what parameters it takes, what the address of the method will be, etc. Include SFML/Graphics/RenderWindow.hpp in your cpp file and it should go away. Better yet, use sf::RenderTarget instead.

I know it is not a link error, what I was saying is that it looked like one.
I did try your suggestion but no success

I'm kind of worried that you might have included inside of a namespace block, with all of those namespaces. That would prevent it from being included again (because include guards are on the preprocessor level, which doesn't give a damn about namespaces), while hiding the sf::RenderWindow declaration in one of your own namespaces. Check for include directives inside of namespaces anywhere. Try using IntelliSense to probe your own namespaces for a sf namespace. Try running the file through the preprocessor (/E or /P /Fi) and searching for all instances of "class RenderWindow" to see where the file's being included.

Thought it might be it, after looking at all instances of #include none were in a namespace Good guess though.

Can you post the preprocessor output?

Here is the pre-processor output from Lightning Sprite.cpp (were the lines I sent before were from) http://pastebin.com/g2uCstsy
I noticed since when you compile with /P in Visual Studio it doesn't generate the .obj files, that there were no errors (although there were when I disabled /P), I dont know if this is kinda a derp or not

Is this the entire thing? There should be a whole lot more than that. It should be tens of thousands of lines long.

It looks like he pastebinned the output of the preprocessor, not the generated file

Ginto8 wrote:It looks like he pastebinned the output of the preprocessor, not the generated file

There were multiple (.i) files, what should the extension and location of the "output" file be?

THe Floating Brain wrote:

Ginto8 wrote:It looks like he pastebinned the output of the preprocessor, not the generated file

There were multiple (.i) files, what should the extension and location of the "output" file be?

If you enabled "Preprocess to a File" in Visual Studio, the preprocessed files should be in your intermediate output folder with a .i extension. Most of them should be several megabytes large. If you need help inspecting the file, paste its entire contents somewhere.

It kinda contains all the definitions for all my classes, including the ones that dont have source file (I dont really want to give all that away) what parts of the file do you need?

THe Floating Brain wrote:It kinda contains all the definitions for all my classes, including the ones that dont have source file (I dont really want to give all that away) what parts of the file do you need?

If you can't cut out the definition of the class implemented in the source file and leave the declarations, you'll probably just have to analyse the file yourself unless you have a really long time to remove all of your declarations.