I was exploring SDL2.0 learning from a lazy too tutorial. In lesson 10 the tutorial introduces a class for rendering. I carefully looked over this code and there is one thing I don't understand. What is "LTexture gSpriteSheetTexture;"? The class is named LTexture yet in the global area outside of the main function I see this declaration. I don't understand. It's like he declare a variable of type LTexture. Please look at the code of the tutorial and explain what, why, and how this strange declaration work.

http://lazyfoo.net/tutorials/SDL/10_color_keying/index.php

He is creating a variable of type 'LTexture'.

When you create a variable outside of any function, it's called a "global variable", and it's generally bad practice, because it can be accessed from anywhere that has 'sight' of it, which can lead to tightly-coupled chunks of code that shouldn't be coupled, or functions that behave differently despite being passed the same inputs.

Used in moderation, global variables can be convenient, but the risk is you get addicted to that convenience and then stop using them "in moderation", and start using them by default, creating messier code logic that is harder to maintain and harder to debug.

In small tutorial examples, it doesn't matter much, but in actual projects, they can become a problem if used too widely. Programming is always about trading pros and cons.

It's like he declare a variable of type LTexture.

I'm only used to standard variables being global. Even the custom made ones I defined in structs don't have functions. I don't like this but should I make an exception with this one class?

If you're following the tutorial, it's fine to do it the way the tutorial says.

Globals can be any variable type - ints and floats, or custom classes. It doesn't matter what type it is, the same guideline applies.

In general, unless the variable is const, it's frowned upon to have global variables. If it's a global const variable, then it's fine to have dozens or even hundreds of those (basically, that's an intermediary step to making many of those configuration variables data-driven, and others you want to keep fixed at compile-time).

Usually, there are a few non-const global variables that escape the axe though: Logging instances (to output log messages), for example. Things can certainly be over-engineered in the other direction as well, if you try to contort too hard to avoid globals but aren't yet sure how.

Singletons are also just global variables in disguise, so the same rules apply: Limit their use as much as possible, but two or three globals in a large project aren't uncommon. It's hard to learn good architectural practice, and global variables or singletons are most often (but not always) a bandaid to work around bad architectures - in my inexperienced opinion.

I'm only used to standard variables being global. Even the custom made ones I defined in structs don't have functions. I don't like this but should I make an exception with this one class?

Another problem with mutable globals is thread safety - you need to protect access to the writeable data with a mutex or other synchronization. Immutable globals are fine though.