After a long post history I still don't quite get your intention. So I'll
The former is procedural though and probably hard to grasp for someone
learning how to program and using the OO paradigm.
This is not true. OO in its very nature is procedural. And don't forget
the design of C++ tried very hard NOT to force people thinking in any
certain paradigm in particular (such as OOP.) In addition,
C-compatibility is important therefore anything that easily breaks C
programs will not be considered.
That's not the only
reason for looking for a better startup architecture: there's probably a
number of other things that an alternative program initiation/startup
would afford (don't ask me what those are, I just wish the compiler
and language designers would think about it some more. Perhaps ordered
initialization could be handled better, I dunno).
Seriously, you can do all these in the plain old main() easily, and
elegantly. You can do an object-oriented program with main(). The
following program is perfectly fine on me:
#include <vector>
#include "shapes.hpp"
int main()
{
std::vector<shape*> v = load_shapes_from_file("shapes");
v.push_back(new triangle);
v.push_back(new rectangle);
for_each(v.begin(), v.end(), print_shape(window::main_window()));
for_each(v.begin(), v.end(), deallocate);
return 0;
}
If you find it hard to say the above is an OO program, you'd better rethink.
Your class C is "MFC-like" in that it just encapsulates the existing rather
than doin something new or more along the lines of OO application
frameworks. I know that classes are just things built up from C structs and
function pointers, but maybe viewing the whole program from an OO
perspective would yield some treasures.
Again, C++ is quite more than just a "pure OO language" in that it gives
you freedom to choose what you want. And OO isn't always the best way to
construct a program. And making main() a virtual member function doesn't
make you a good OO program anyway.
If you want an alternate entry point, you can easily achieve it like this:
/// chess_game.hpp ////////////////////////////
#include "all_my_includes.hpp"
#define ENTRY_CLASS chess_game
#define ENTRY_POINT start_chess_game
class chess_game
{
// all well designed OOP style stuff...
// and others
// entry point
virtual int start_chess_game()
{
// ...
}
};
// main.cpp //////////////////////////////////
#include "chess_game.hpp"
int main()
{
ENTRY_CLASS entry;
return entry.(ENTRY_POINT)();
}
I usually think of OO in terms of how it makes large scale project
manageable. The primary tool is designing libraries that are flexible
and well encapsulated. A standalone main() certainly doesn't stand the
way thereof.
In a lot of cases, better encapsulation means using more standalone
non-member functions since they are encapsulated from the class internals.
Again, not as a replacement for
the procedural C style, but as an additional alternative. Who knows, maybe
rearchitecting (thinking about it) would show that the C style is to be
"emulated" rather than the OO style. I just wonder about it, as I have no
intention of getting deep into compiler or hardware stuff.
Perhaps a little reading will make my point clearer:
http://www.artima.com/intv/goldilocks.html
http://www.artima.com/intv/modern.html
http://www.artima.com/intv/abstreffi.html
http://www.artima.com/intv/elegance.html
Those are very interesting interviews with stroustrup and in my opinion
quite insightful.
Ben
