SFML community forums

Help => General => Topic started by: paupav on December 28, 2014, 01:35:53 pm

Title: Is it fine to have sf::Font and sf::Text as global
Post by: paupav on December 28, 2014, 01:35:53 pm

So, i have

namespace menu
{
    void loadFiles();
    void menu(sf::RenderWindow &window);
    void main(sf::RenderWindow &window);
    void options();

}

and I have sat up Text and Font inside the menu::loadFiles, and I'm drawing it inside the menu::main(). I've made them global so that I can use it inside both functions and I wanna know is it fine to have them global or should I find some other way?

Title: AW: Is it fine to have sf::Font and sf::Text as global
Post by: eXpl0it3r on December 28, 2014, 01:41:04 pm

It's bad design and can lead to crashes. In most cases using globals to solve a problem is a bad decision.

Manage the font with for example a ResourceHolder and create the text object where you need it.

Title: Re: AW: Is it fine to have sf::Font and sf::Text as global
Post by: Mörkö on December 28, 2014, 04:19:19 pm

Quote from: eXpl0it3r on December 28, 2014, 01:41:04 pm

It's bad design and can lead to crashes. In most cases using globals to solve a problem is a bad decision.

Can you show some examples of where people experienced crashes explicitly due to using globals (threads on the forum etc)? Alternatively a small code example reproducing a bug caused by a global variable.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Jesper Juhl on December 28, 2014, 04:27:13 pm

Just search the forum. There are plenty of threads.
Some of the SFML classes have interdependencies that go wrong when the classes get destructed in the wrong order (which you lose control over with globals in different translation units).
And even if you don't get crashes, designs involving globals (including singletons, which are just globals by a different name IMHO) are usually bad anyway for loads of other reasons (tight coupling, hard to refactor, multiple globals depending on individual construction/destruction order, globals being constructed before main() and destroyed after it ends and not being able to deal with that, functions having hard to predict side effects due to modifying globals, objects living longer than they need to (since they are global) and needlessly consuming resources. Etc etc etc).
Just try to avoid globals - please ;-)

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: StormWingDelta on December 28, 2014, 06:15:14 pm

From what my teacher said the only globals that are safe are primitives like, int, double, bool, string, etc.  Like others have said here when it comes to objects the order they are destructed in as globals is undefined and can cause crashes because of it.

So:

namespace menu
{
    void loadFiles();
    void menu(sf::RenderWindow &window);
    void main(sf::RenderWindow &window);
    void options();

}
 

Should/Could be:

class menu
{
public:
    void loadFiles();
    void menu(sf::RenderWindow &window);
    void main(sf::RenderWindow &window);
    void options();

}
 

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Ixrec on December 28, 2014, 06:31:41 pm

Quote from: StormWingDelta on December 28, 2014, 06:15:14 pm

From what my teacher said the only globals that are safe are primitives like, int, double, bool, string, etc.

Gonna have to disagree there.  First, string is not a primitive.  Second, a global int has all the problems one would normally associate with a global.  In particular, everything can change it, so you can quickly lose control of how it's being changed and end up with brittle code in a sufficiently large program.  Third, if you had a global struct, splitting that into its constituent global primitives wouldn't make the globalness any less problematic (if anything that would be slightly worse).

The only globals I would call "safe" are global constants.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: StormWingDelta on December 28, 2014, 06:47:14 pm

The only globals I'd ever use anyways are ReadOnly/constants, Kinda forgot to finish that line. :(  Basically the only good globals are either none or readonly ones that aren't objects or messing with objects.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Neil on December 29, 2014, 12:31:04 am

I'm not sure what you gain by just switching the namespace to a class.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Ixrec on December 29, 2014, 12:39:42 am

I think his post was missing a lot of things he intended to put in there.  I assume those code samples were meant to look more like this:

namespace menu
{
    sf::Font evilGlobalFont;
    sf::Text evilGlobalText;

    void loadFiles();
    void menu(sf::RenderWindow &window);
    void main(sf::RenderWindow &window);
    void options();

}

class menu
{
public:
    void loadFiles();
    void menu(sf::RenderWindow &window);
    void main(sf::RenderWindow &window);
    void options();
private:
    sf::Font goodEncapsulatedFont;
    sf::Text goodEncapsulatedText;
}

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Jesper Juhl on December 29, 2014, 12:46:14 am

I fail to see how that makes things radically better...

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Gambit on December 29, 2014, 01:01:24 am

Maybe make "menu" a full public singleton?

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Neil on December 29, 2014, 02:04:37 am

What if more than one thing in your program uses the font, won't that way load it into memory multiple times?

This is why I suggest a global repository of non-modifiable resources sourced from disk. Properly managed in such a way that nothing is loaded before main function is called, and everything gets unloaded before the exit of main.. or pass it as a pointer to all your stuff.

I wouldn't make the menu object itself a global variable, which a singleton essentially is. From what I've seen, it doesn't need to store any state at all.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Gambit on December 29, 2014, 02:16:21 am

Global objects suck. That is a really well known fact about C++ due to them having weird destructions and so on. Singletons arent global variables. If you use it write, you should have any problems. That being said, its a cheap workaround for the real issue here. paupav should implement a proper state system into the application and use a context-type system for handling data (Like resources) between states.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Neil on December 29, 2014, 02:31:50 am

A singleton is a nicely packaged global variable, which can solve some problems such as creation order. However as far as other design aspects are concerned, they suffer many of the same problems as global variables. So I consider them practically the same. After all, the singleton has a "static" in there somewhere, right?

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Gambit on December 29, 2014, 02:41:27 am

Like I said though, singletons arent variables. You cant get the address of a singleton, you can only call the static members of it. Singletons can fix issues properly (That is, not using them as an ugly hack) but thats usually because they dont store states for anything, the state is created in the function calls and generally returned.

In the case of a resource manager, a singleton is a pretty bad idea, especially if you want multiple caches. That being said, it all comes down to personal preference and if you want to use a singleton or global variables for states or whatever thats all on the programmer.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Neil on December 29, 2014, 02:46:29 am

You can get the address of this singleton:

http://stackoverflow.com/questions/270947/can-any-one-provide-me-a-sample-of-singleton-in-c/271104#271104

Why is a singleton a bad idea for a resource manager which stores unchanging resources loaded from disk? I'm not a singleton fanatic, believe it or not, but if there's ever a good use of a singleton, this seems to be the one.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Gambit on December 29, 2014, 02:56:08 am

I forgot about instance functions and thats not exactly what I meant. If you dont have any "instance" of a singleton, but instead just a class with static methods (Like sf::Keyboard), you cannot get the address of it.

My main argument for not using a singleton is that if you dont handle your instances properly then the destruction can cause crashes when exiting the program (But who cares right? It's already closed). Otherwise, as long as the structure is robust and all that good stuff I dont see why it cant work, just my preference I suppose.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Ixrec on December 29, 2014, 03:01:38 am

While I tend to lean on the side of singletons being just as bad as globals, at some point it comes down to how you define a "singleton," and I suspect we're on the verge of talking past each other because of that.

The key thing in this context is that the resources (fonts and texts) should have a clear ownership and access policy that the implementer consciously chose.  Globals and singletons typically result from programmers not bothering to think about that, which is the real reason they're so problematic.

paupav has to make this choice since he knows far more about his program than we do.  But I can think of at least three sane options that might fit:

1) If the "menu" class is the only thing that ever uses these resources, then those resources should be static members of menu, the constructor loads them if necessary, and nobody except menu's methods gets access to them.  Nice and simple.

2) If there are multiple GUI objects that all share these resources (say a few menus, some buttons, some labels, and so on), it may make sense to have a class like GUIManager that owns the common resources and passes them to the individual objects (hopefully in the form of a const reference).  Maybe you already have a class managing all these objects and this should simply be added to it.

3) If multiple objects share these resources and a manager class doesn't make a lot of sense for whatever reason (nothing else for it to manage, the objects are all of very different types, etc) then you should create a class that does nothing but manage resources and instantiate it in main().  You then pass the rest of your objects/subsystems a reference (again, ideally const) to either the manager itself or specific resources it loaded.  There may be a little bit of #2 involved here if your program has a lot of layers.

#3 is probably what most of us would recommend doing in most game-like programs.  It may seem like a pain because you have to pass a resource or a resource manager through a bunch of functions instead of just making them globally accessible, but that's a good thing.  It forces you to design your classes and their interfaces in a way that makes it easy to inject dependencies like this, rather than relying on a singleton or a bunch of globals just "being there".

Personally, the only thing that I have no qualms about making global/singleton is a logger.  You want the ability to log stuff in literally every single function in your program, and you want there to be only one logger for all those functions, but adding an extra parameter to literally every function is a bit silly.  A resource manager class definitely shouldn't be used in every function, so you should at least make an effort to do that without a global/singleton.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: paupav on December 30, 2014, 05:40:17 pm

Ok, I just wanted to know if there is any downside of having it global, and I've got answer.
I will try to find out what is Resoruce Manager such as:
 https://github.com/SFML/SFML/wiki/Tutorial:-Image-Manager

@Ixrec Thanks for the alternatives, but I think that resource manager should work fine in this case, so I'll stick with #2.

So I have to replace namespaces with classes then.

Also I've found this and I think that this should be in the tutorials.
https://github.com/SFML/SFML/wiki/FAQ#prog-global

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Ixrec on December 30, 2014, 05:55:29 pm

In principle doesn't belong in the SFML tutorials because they're tutorials about SFML, not general programming or C++ programming.  But considering how much general programming stuff is already in that FAQ, and scattered all over this forum, I wouldn't exactly be opposed to the tutorials having a "General Programming Guidelines" section at the top to cover "basic" things like globals and RAII for the newbies we inevitably get.  That might be worth a thread over in general discussions.

I skimmed that Image Manager tutorial just to be safe and it looks pretty good to me.  The only thing I'd mention is that since all that code specifies sf::Image, if you ever want multiple types of resources to be neatly managed you may want to make it a template class.

Title: Re: Is it fine to have sf::Font and sf::Text as global
Post by: Jesper Juhl on December 30, 2014, 06:08:28 pm

Quote from: Ixrec on December 30, 2014, 05:55:29 pm

In principle doesn't belong in the SFML tutorials because they're tutorials about SFML, not general programming or C++ programming.  But considering how much general programming stuff is already in that FAQ, and scattered all over this forum, I wouldn't exactly be opposed to the tutorials having a "General Programming Guidelines" section at the top to cover "basic" things like globals and RAII for the newbies we inevitably get.  That might be worth a thread over in general discussions.

Yeah, a well thought out list of common problem issues/topics and better ways to do things that we can point new users at would be good. Perhaps we should just create a wiki page for that.

Quote from: Ixrec on December 30, 2014, 05:55:29 pm

I skimmed that Image Manager tutorial just to be safe and it looks pretty good to me.  The only thing I'd mention is that since all that code specifies sf::Image, if you ever want multiple types of resources to be neatly managed you may want to make it a template class.

Or one could just use the Thor Resource Module (http://www.bromeon.ch/libraries/thor/v2.0/tutorial-resources.html).