Classes are actually a very good for debugging and stopping Linking Errors if you wanted to pass variables around in functions very easily with out having to make them global which sometimes can get the compiler confused if you had tones of header files.
Whats So Great About Classes
I suggest you read it, and find out yourself before you find out the hardway when you first develop your large project.
Are classes evil?
Don't stick everything into classes, only the relevant bits.
How Non-Member Functions Improve Encapsulation
How Non-Member Functions Improve Encapsulation
Quote:Original post by McCoder
So sticking the WinApi Winmain in a class would be classified as "good"?
You can't do that, it won't work.
WinMainCRTStartup wants WinMain not SomeClass::WinMain.
It would be pointless anyway, since WinMain is just an entry point into the application. So in my opinion (I'm sure someone will disagree), it's not classified as a good thing.
Quote:Original post by McCoder
So sticking the WinApi Winmain in a class would be classified as "good"?
A lot of people are going to come in here and tell you how not to put this code in a class. They're going to tell you to follow the single responsibility principle, they're going to stress encapsulation, data hiding, and proper OO paradigms. Most people get so caught up in designing their program in the proper OO way that they never actually finish something. That's why many people are on their second, third or even fourth rewrite of their game-- er, engine.
For a small project like an arcade-style game, things like proper OO design and principles are just going to keep you from your goal of creating a working game, especially if you haven't a lot of experience finishing games. My advice is to wrap that stuff up in classes if it helps you get your game done. You might step on your own foot a few times, but you'll learn and for your next game you'll do it better. And you'll be three steps ahead of us who're on our third engine rewrite.
Author
Quote:Original post by polymorphedQuote:Original post by McCoder
So sticking the WinApi Winmain in a class would be classified as "good"?
You can't do that, it won't work.
WinMainCRTStartup wants WinMain not SomeClass::WinMain.
It would be pointless anyway, since WinMain is just an entry point into the application. So in my opinion (I'm sure someone will disagree), it's not classified as a good thing.
So wether I like it or not, I always need to have a WinMain in my main.cpp file. Ugly, I guess it's pointless to have two WinMain's then.
Author
I dont, but even if I class WinMain, I still need a WinMain as the main entry point for the game right? Or can I do something like MyClass WinMain(1, 2, 3)?
Well, yes you will need a free function of WinMain. But the point is that I cannot see why you would create a class for WinMain. What would it do? What members would it have? You could have a class for window creation maybe, but not the entry point itself.
You must have a WinMain putting it in a class does not work but you can pass the control to you application class in the WinMain :
The app class run method can call an init function then enter a message loop and handle the application.
int WINAPI WinMain(...){ boost::shared_ptr<Application> myApp(new Application()); return myApp->Run();}The app class run method can call an init function then enter a message loop and handle the application.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
