Archived

This topic is now archived and is closed to further replies.

EvilCrap

CPROGRAM

Recommended Posts

EvilCrap    134
hi. lately, in c++, when i go to write a program, i so want it to be really object oriented. ive encountered a problem. basically, its not possible to write a completely object oriented program because the entry, main/winmain, is not associated with an object. ive been trying to figure gimiks so that an object seems to associate with the entry, and ultimately the behavior of the overall program, but coding has been exceptionally crappy. i try to write a header that encapsulates the entry, and then calls class members that the user would have written, like, program::init(), and program::destroy(), but i really hate the idea of the user writting the implementation to a declared class, even though thats what i want to accomplish. what do you people think?

Share this post


Link to post
Share on other sites
WayfarerX    130
Take a look at the DirectX 8 Common Files. They do what you're talking about (essentially).

"So crucify the ego, before it's far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that's imagined and all conceivable."
- Tool
------------------------------


Edited by - wayfarerx on January 15, 2002 11:38:53 PM

Share this post


Link to post
Share on other sites
abdulla    164
why do you want to anyway? don''t you think your taking the notion of "object-orientation" a bit too far? oop design isn''t always the best way to do things, its when its combined with different styles to make a successful program that i works, it isn''t always the best way/choice to do things, c++ wasn''t made to do pure oop design.

Share this post


Link to post
Share on other sites
kvh    122
I agree with abdulla, what do you gain by encapsulating the global entrypoint? C++ is not an object-oriented language, although you can use object-oriented techniques. The fact that you can use a global main() is an advantage. Object-oriented languages like Java and C# don''t have this option, there you implement it like this:

  
class Game {
public:
static int main() {
return 0;
}
};


I don''t see why that would be better than:

  
int main() {
return 0;
}


And it typically leads to something similar to:

  
class Game {
public:
static int main() {
Game game;
return game.run();
}
};


Is that confusing or what?

And if you want to get rid of WinMain(), or you want to perform initialization and cleanup of your library, you can always create you own entry point:

  
// engine.h


namespace engine {
int main();
}

// engine.cpp


#include <engine.h>

int APIENTRY WinMain(HINSTANCE, HINSTANCE, char*, int) {
// setup

int result = engine::main();
// cleanup

return result;
}


and let the user implement it:

  
#include <engine.h>

int engine::main() (
return 0;
)


It''s still possible to use your Program base class, and give the user the choice to derive from it, but he gets to decide when and how it gets created and destroyed. It''s also easy to wrap everything in a try/catch block. This approach is not only more flexible, but probably also cleaner than the hacks you''d have to implement to create the right derived class. In addition, the user will get a compile time error when he forgets to implement your engine::main().

for example:

  
class Test : public Program {
virtual int run() {
//setup

int result = Program::run();
//cleanup

return result;
}
};

int engine::main() {
Test prog;
return prog.run();
}


BTW: If a Program class that gets created by the program feels a bit wrong conceptually, you can always try something like ''EventDispatcher'' if you like.

Share this post


Link to post
Share on other sites
jwace81    160
I believe that it is possible to wrap WinMain inside a class, I''m pretty sure that the MFC WinApp class (i believe that''s the one) does it. However, as the others have already said, you don''t really gain anything by this. And what is not object oriented about possibly just creating the base object inside the main/WinMain function and then passing control on to them. That is in essence what Java does with the main entry point inside the class instead of outside the class. Just because the entry point in a Java program is inside the class does not make Java a pure OOP language. In fact, if you wanted to, in Java, you can write code that is completely procedural, aside from the fact that it is encapsulated inside of a class (it has to be only because that''s the way Java works). There is no such thing as a pure object oriented language.

j.w.

Share this post


Link to post
Share on other sites
kvh    122
  
// library code


#include <cassert>

class App {
protected:
App() {
assert(!inst_ptr);
inst_ptr = this;
}

virtual ~App() {
inst_ptr = 0;
}

public:
static App *getInstance() {
return inst_ptr;
}

public:
virtual int run() = 0;

private:
static App *inst_ptr;
};

App *App::inst_ptr = 0;

int main() {
App *app_ptr = App::getInstance();

assert(app_ptr);

return app_ptr->run();
}

// user code


class MyApp : public App {
public:
virtual int run() {
return 0;
}
};

MyApp theApp;


this is similar to MFC, but I still don''t see the point

Share this post


Link to post
Share on other sites
Kylotan    10008
That code will leak your memory for the App. (Ok, so the OS should reclaim it, but even so...)
Remove the inst_ptr stuff and do this instead:

static App* getInstance()
{
static App theInstance;
return &theInstance;
}


[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
kvh    122
inst_ptr is assigned a this-pointer, the actual instance is created as a global variable, so it's destroyed when the program ends. I used this approach because the 'static App theInstance' stuff is encapsulated in the base class, and there's no easy/clean way to detect which derived class is to be instantiated.

Edited by - kvh on January 22, 2002 4:59:31 AM

Share this post


Link to post
Share on other sites
abdulla    164
i don''t like using static variable because they can get tangled, in your case if you have more than one copy of your class and you switch between the static variable will be inaccurate, and it sort of seems dirty to me, if i need to bind a member function to something or expose it i use a pointer callback that i bind the this pointer to, this is a seperate context to the class itself to avoid confusion

Share this post


Link to post
Share on other sites
kvh    122
quote:

in your case if you have more than one copy of your class


I''m not sure that I understand what you''re saying, but the since we''re implementing a singleton, there won''t be more than one instance...

Share this post


Link to post
Share on other sites