Undefined reference errors

[carton83]

Hi all, I am just getting into SFML.  I was setting/compiling up 2.1 on my LMDE partition by following the 2.1 tutorial in the official resources and afterwords I try compiling a simple program to test if everything works.  I end up failing because the linker can not find anything related to SFML.

Here is the code.

#include <SFML/Graphics.hpp>
bool events(sf::RenderWindow &window)
{
    sf::Event event;
    window.pollEvent(event);

    if(event.type == sf::Event::EventType::MouseButtonPressed)
    {
        return true;
    }

    return false;
}
int main()
{
    sf::RenderWindow window;
    window.create(sf::VideoMode(400, 400), "Test!");
    window.setFramerateLimit(4);

    while(!events)
    {
        window.clear(sf::Color(0,0,0));
        window.display();
        window.clear(sf::Color(128,128,128));
        window.display();
    }
    window.close();
    return 0;
}

Any idea as to what I can do to figure out what went wrong?

[eXpl0it3r]

Your linker can't find the libraries, so you have to tell it where to look out for them.
Where have you installed the libraries to and is that path in ld's linker path?

You might want to read a few things on your linker.

[G.]

On a side note, if this code is from a tutorial you should abandon it and follow the official ones instead because it is very bad.

[carton83]

Your linker can't find the libraries, so you have to tell it where to look out for them.
Where have you installed the libraries to and is that path in ld's linker path?

You might want to read a few things on your linker.

Well like I said, I followed the how-to compile guide from the official resources, so the cmake file put everything in /usr/local.  How do I figure out what directories g++ looks in when linking?

On a side note, if this code is from a tutorial you should abandon it and follow the official ones instead because it is very bad.

What makes it bad?

[zsbzsb]

What makes it bad?

The entire structure of that code is a piece of crap, just try comparing it to one of the official tutorials...

Where to start....

• Bad game loop
• Bad event loop
• Bad drawing code
• Incorrect event polling
• Needless to say stop following whatever gave you that code

[carton83]

Okay, why is it bad?  I can't really learn anything if I'm not told why "x" is bad.  Could you please explain?

[zsbzsb]

Read the official tutorials. How to do everything is explained correctly there.

http://www.sfml-dev.org/tutorials/2.1/

Compare your code to the official tutorials and follow the logic, you will see why it is bad 

[carton83]

That's a bit of a cop-out of an answer.  You're not really telling me anything.

I don't understand why it's "bad".  If I can get it to compile (assuming I can get help with my linker issues) it should do what I want it to, which is to have the window go from black to gray twice in a second unless I hit the x button.

[zsbzsb]

That's a bit of a cop-out of an answer.  You're not really telling me anything.

I don't understand why it's "bad".  If I can get it to compile (assuming I can get help with my linker issues) it should do what I want it to, which is to have the window go from black to gray twice in a second unless I hit the x button.

It is not a "cop-out" answer. The reason I am telling you to learn from the official tutorials is because it is impossible to learn from bad code. Once you learn the correct way to do something it is very easy to spot the incorrect ways. There are so many incorrect ways of doing something vs generally a few ways of correctly doing something. Take for example the recognition of counterfeit money, people studying to identify counterfeit money study the real stuff (source) and not the fake. Once they can recognize the real money it is a piece of cake to identify counterfeit money. The same applies to coding, you can't learn from bad code (or learn from someone constantly telling you exactly what your mistakes are).

Your code may work correctly at the moment, but it is like crossing your fingers. It may work one time and not work another. I will give you an example of this, in your event polling you do not even check if there was a valid event - so essentially you are crossing your fingers and hoping that you are not actually reading corrupted data.

Once again I will say this, go read the official tutorials since they cover everything that you are doing wrong here.

[carton83]

you can't learn from bad code (or learn from someone constantly telling you exactly what your mistakes are).

Yes you can.  Or at least I can.  If I figure out why something does not work or someone else explains then I'll know why I shouldn't do that.  You can't just expect me to blindly trust another person when they say I've done something wrong or incorrectly without them at least telling me why.  Telling me to "go read the tutorials" isn't really giving me much other than "figure it out yourself".  That isn't helpful.   I need to not only know what is correct, but what isn't and understand why.

Also, that blog doesn't list *any* sources.  Not to mention it's factually incorrect.  They do study counterfeit money.  They do so  in order to know the characteristics of counterfeits versus those of genuine cash and they even encourage the public to do so as well.(actual source)

Edit:  Thought I included this, but thank you for explaining why on at least one part.

[Laurent]

I think he told you to read the tutorials because your code seems to come out from nowhere. Guessing how to use a library is not the way to go. You first need to learn the basic stuff before trying to go further -- and guess what, all you need to know to correctly get started with SFML is described in the tutorials and the documentation

Now if you still don't want to read that first, here is a list of your mistakes:
- You should have an event loop, and use the sf::Event instance only when pollEvent returned true. Here, all you have is undefined behaviour.
- while(!events) checks the value of the "events" function -- it is always true, it is a non-null address in memory. What you want is to call the function (with an argument) and then check its return value.
- Although it is not incorrect, your drawing code is weird. You're not supposed to call clear/display several times per frame. But let's say it was just for testing
- You don't need to explicitly close() the window, the destructor takes care of that.

[carton83]

Thank you so much for that!

I decided to look through the Sid repositories to see if they had 2.1 and it turns out that they do.  So no more linker errors for me!

Never mind on that >:|