(Source is attached, there's too much to code tag in here.)

Hello, ive recently spent alot of time working on improving my OOP knowledge so i can make a game where the code files don't make me sick .

i would like some experienced C++ Programmers(SFML knowledge or Not) to review my code and let me know of any bonehead mistakes ive made, or areas where i could improve something, that kind of thing.

i do ask that you please don't comment on the formatting of the text, or something of the like.(i.e.things that don't help me with OOP, things that are mostly/wholly subjective opinions, Unless you 100% whole heatedly think that it is something that i need to know and would be very beneficial to me.)

Thanks!

(as of the build you guys can download, debug & release run perfectly and there is no errors (at least none ive noticed in the many hours with it.)

(also id like to note, currently this isn't a game of any kind, im just working on mechanics (Gravity, Collision, Ect.) and as my knowledge grows i will slowly piece it into a game.)

Most issues that I see have to do with code organization.

• `using namespace` in non-local scope is a shooting offense. You put it in a HEADER. Code police is on its way. Please assume the position.
• Global variables are a no-no. I could understand global `Objects` but global iterators? Whoa...
• Whenever possible, prefer range-for to iterators when working with std containers. It makes for a much cleaner code and you don't have to keep coming up with a name for each iterator. ;)
• `auto` is your new best friend. Use it wherever possible.
• Consider encapsulating each logical part of the update loop in a "system". A function, f.ex. `doDeadCulling(std::list<GameObject>& objects)` would do the trick.
• Two-phase initialization is not necessary in your case. Have your `Player` and `Enemy` call `GameObjects` constructor with appropriate parameters as the first statement in their respective constructors.
• Base class destructors must be marked virtual, else nasal demons. This applies to every class that will be inherited from. Not just the class at the root of hierarchy. In your case, `GameObjects`'s destructor is in error.
• Your `GameObject` is responsible for way too much. There are two possible ways to deal with this. Classic way would be to split it into various abstract base classes, f.ex. `Drawable` and `Collidable`, and have your `Player` and `Enemy` multiply-inherit from those. Modern approach would be to use a Entity Component System (ECS). It has many advantages over the classic aproach. Your favorite search engine should give you a couple of good hits.
• You lose a game vs. your pants are loose.

I'm happy to expand on these points if you have questions.

Most issues that I see have to do with code organization.

• `using namespace` in non-local scope is a shooting offense. You put it in a HEADER. Code police is on its way. Please assume the position.
• Global variables are a no-no. I could understand global `Objects` but global iterators? Whoa...
• Whenever possible, prefer range-for to iterators when working with std containers. It makes for a much cleaner code and you don't have to keep coming up with a name for each iterator. ;)
• `auto` is your new best friend. Use it wherever possible.
• Consider encapsulating each logical part of the update loop in a "system". A function, f.ex. `doDeadCulling(std::list<GameObject>& objects)` would do the trick.
• Two-phase initialization is not necessary in your case. Have your `Player` and `Enemy` call `GameObjects` constructor with appropriate parameters as the first statement in their respective constructors.
• Base class destructors must be marked virtual, else nasal demons. This applies to every class that will be inherited from. Not just the class at the root of hierarchy. In your case, `GameObjects`'s destructor is in error.
• Your `GameObject` is responsible for way too much. There are two possible ways to deal with this. Classic way would be to split it into various abstract base classes, f.ex. `Drawable` and `Collidable`, and have your `Player` and `Enemy` multiply-inherit from those. Modern approach would be to use a Entity Component System (ECS). It has many advantages over the classic aproach. Your favorite search engine should give you a couple of good hits.
• You lose a game vs. your pants are loose.

I'm happy to expand on these points if you have questions.

Thank you so much!

ive copied your post to my ToDo list and will start working on them later today.