[solved]Global sf::Renderwindow used in derived class

[Steef435]

Hello all,

Perhaps I better say this first: I'm not sure if this is a question related to sfml or if I'm just being stupid at C++.
I fear for the latter

I'm using the latest snapshot built on Ubuntu 12.10, my compiler is gcc.

This is my problem:
I'm trying to learn about different techniques for state-changing(from intro to menu etc.).
The one I'm now trying to implement uses a base GameState class which will be derived by all the states(not exceptional).
So that class, which looks something like this:

class Gamestate
{
    GameState(){};
    virtual void logic() = 0;
    virtual void input() = 0;
    virtual void render() = 0;
}

I derive in my Intro class.
I have a global sf::RenderWindow* window which I use in my derived class.
My input()-function looks something like this:

void input()
{
    sf::Event event;
    while (window->pollEvent(event))
    {
         //process input...
    }
}

This all compiles fine but when I try to run this program it gives me a segmentation fault(core dumped).
I'm pretty sure it has nothing to do with my state-system, the debugger tells me the program gives the error after the first call to the RenderWindow out of my Intro-class, in the input function at the first line of pollEvent in Window.cpp.

Yes, I did initialize(is that the right word?) the RenderWindow, I did even call create() right after that just to be sure.

Again, I'm still quite new to C++ and sfml, so it could be something stupid I overlooked.

It would be very nice if someone could help me out with this, I'm already looking at this error for over an hour...

Regards,
Steef

[Nexus]

Don't declare the window as a global variable. It is not necessary, and while making things seemingly simple, it brings a lot of trouble (see detailed explanation).

And your polymorphic base class should have a virtual destructor.

[Steef435]

Yeah, I know global variables are all bad, but I thought throwing around references shouldn't be good either(your article doesn't agree ).
It did fix the problem to just add a reference to the class, however. Quite strange if you ask me.

You're right, and the constructor shouldn't be there either. I just wrote it out of the top of my head.

I also have another question, if the mod doesn't mind me .
In the tutorial I'm following(a bit) they use a global function(and two variables used by it) to change the states, since the current state should be able to do so too(setting that in the next main-loop the state will be changed).
Should I also avoid that, and if so, how should I?
I could create a Statemanager-class that gives each state he "owns" a reference to itself, but wouldn't that be messier/worse?

Thanks for the help!

[Nexus]

Can you show a short code that shows the principles of your state-changing function? What state is that exactly?

And don't confuse global functions with global variables. The former are perfectly fine -- in fact, a member function is not much more than synctactic sugar for a global function that takes this as first parameter.

[FRex]

Since I'm struggling with genociding globals and singletons too, could you point us to some good reading about dependancy injection and grasp pattern, Nexus?

[Steef435]

Can you show a short code that shows the principles of your state-changing function? What state is that exactly?

And don't confuse global functions with global variables. The former are perfectly fine -- in fact, a member function is not much more than synctactic sugar for a global function that takes this as first parameter.

Well, it's not actually a state, but more like a switch between the main menu, the intro, the game itself etc.
I hope this makes it clear:

enum GameStates {
    STATE_NULL,
    STATE_MENU,
    STATE_GAME,
    STATE_EXIT
};

int next_state = STATE_NULL;
int stateID = STATE_NULL;
Gamestate* current_state;

void set_next_state(int newState)
{
    //at the end it could set next_state to a new value, for example STATE_MENU
}

int main()
{
   if (next_state != STATE_NULL)
   //set new state
   current_state->input;enum
   current_state->drawings;
}

There is also another function which actually creates and deletes the states, but I left it out for the sake of compaction. This function also needs the global variables, of course.
So if let's say STATE_INTRO ends, then the class of the intro will call set_next_state(STATE_MENU).

Thanks again!

[Nexus]

Since I'm struggling with genociding globals and singletons too, could you point us to some good reading about dependancy injection and grasp pattern, Nexus?

Unfortunately not. In my opinion, the term "dependency injection" is too hyped for being a somehow natural approach. And I personally don't find the suggestions to avoid global variables in my link too useful -- instead of trying to enforce some strange design pattern, it makes often more sense to think about responsibities, and put the variables in the corresponding class. Of course this sounds very general, but what is appropriate depends strongly on your current design.

Well, it's not actually a state, but more like a switch between the main menu, the intro, the game itself etc.

Okay, so you already have a hierarchy for surfaces like menu or game, this is a good approach. Instead of placing the pointer to that surface in the global scope, you could move it to a higher-level class Application that controls the application flow. In the end, main() may look only like this:

int main()
{
    Application app;
    app.run();
}

run() is in charge of state changing, it calls the surface's methods (e.g. input(), logic() and render()). These in turn can directly return the enumerator of the next state, so you don't need member variables to store the state enumerators, only one member for the surface instance. And I would do it with std::unique_ptr<Gamestate> instead of Gamestate*

[Steef435]

I'll try that, thanks again!