Manipulating a RenderWindow's view?

[Bones]

Hello there.  I have a RenderWindow called "App" and set it's view to a new one I created called gameView.  I can manipulate this view from my main cpp file because that's where I created it but I want to access the view out of it's scope so I can use the view's move method.  I have a function that takes in the reference of "App", and I can manipulate that, but I can't seem to get the view from it.  I assume I have to use App.GetView() but it doesn't seem to work.  I can say const sf::View var = App.GetView() but I can't call var.Move or manipulate it in any way.  App.GetView() gives you a constant so that might have to do with it.  How do I use it correctly?

PS I'm using SFML 2

[TheEnigmist]

PS: i'm not using SFML, i will start use it tomorrow maybe.
Btw, can you use a global view? Or give a reference of that view to your function?

[Bones]

PS: i'm not using SFML, i will start use it tomorrow maybe.
Btw, can you use a global view? Or give a reference of that view to your function?

Not sure what you mean by global view(EDIT:Oh, I think you mean making it a global variable.  Thanks, I've thought of that too, but I'd like to try and get my current situation to work ), and yes I could probably give the view as a reference to the function but I'd like to keep it simple.  Since the RenderWindow "App" is already a parameter, I'd rather be able to use one of it's methods or properties to reach the view.

Also, here's some example code.  This is all in my main.cpp file for simplification:

Code: [Select]

App.GetView().Move(3,4);

I'd like this to work, but I get an error that says the object has type qualifiers that prevent a match and that there are too many arguments in the function call, yet if I use the view directly and say gameView.Move(3, 4), it will work.

Code: [Select]

const sf::View& view = App.GetView();
view.Move(3,4);

I tried this too, didn't really expect it to work...which it didn't.

[Bones]

Actually making it global would probably work better as then I could access it in functions that don't have "App" as a parameter.

[thePyro_13]

Rather than making it global, you're better off adding a view parameter to the few functions that need it.

This will force you to think about whether a function should be modifying the view or not and will make finding view related bugs so much easier in the future(knowing which functions can modify it makes finding the bug easier).

[Nexus]

Create a copy of the view returned with GetView(), modify that copy and assign it with SetView().

And beware of global variables.

[TheEnigmist]

Create a copy of the view returned with GetView(), modify that copy and assign it with SetView().

And beware of global variables.

Aren't global variables good for make a project well-written, are they?

[Tex Killer]

Create a copy of the view returned with GetView(), modify that copy and assign it with SetView().

And beware of global variables.

Aren't global variables good for make a project well-written, are they?

Global variables can be constructed before SFML own globals, and that would crash your code. If you really want a global variable, try using a global pointer.

[Nexus]

Aren't global variables good for make a project well-written, are they?

No, they make projects badly-written. In the long term, the design suffers from global dependencies, since interactions/maintenance/bugfixes are not local anymore, you always have to consider unwanted side effects. There are many other problems, you find them when you use the search function.

If you find an approach without global variables (or singletons), prefer it, even if it seems to be slightly more tedious in the short term.

[Silvah]

Aren't global variables good for make a project well-written, are they?

No, they make projects badly-written.

No, using globals is unrelated to the quality of the design. You can have good design and have a global or two in the code (however rare it might be). You can have horrible design without any global in sight. And of course you can have good design without globals and bad design with globals. Therefore, the issues are orthogonal. Q.E.D.

Judicious use of globals is okay. Globals aren't the bad thing, the fact that they tend to get over- and misused is.