SFML Game Development Book - Chapter 3 - toTextureID function

[psteiner]

Hi SFML book authors,

I have a question for you about the toTextureID() function on page 62: Why is it defined as a global function? Aren't globals evil? .

I can see that the function might not make sense as a member of the Aircraft class, as it's not really part of the Aircraft API, but couldn't it be a member of ResourceHolder or ResourceIdentifiers, perhaps generalized to take other Resource types? Or am I just anticipating changes to the code at later stage in the book?

BTW, as a beginner to intermediate C++ programmer, I appreciate the way you've included the new C++11 concepts. I learned C++ about 6 years ago & haven't applied it very much since then (one of the reasons I wanted to experiment with SFML). I like to learn by doing, so the book provides a good way to get some practical exposure to the new C++11 features. Every page sends me off Googling about C++!

Thanks
Philip

[thomas9459]

I've never used the book myself, but by the looks of code listing here, the function just does a simple conversion from a Aircraft::Type to Textures::ID. This is just fine, as it makes it possible to do the one-line constructor for mSprite.

When people say that globals are evil, they are referring to global objects, not functions. These cause problems as the order of initialization is not specified, and so heavy-weight objects, such as sf::Window, can cause the program to crash. They also indicate a design flaw, as potentially any part of the program can modify the variable. Both of these obviously do not apply in this case.