I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
return 1;
}
Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
As it is though, even C++ likes procedural main rather than some kind of
"program" class.
Please feel free to add any comments on tangential but associated topics
also.
Tony
43  2032 
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
>
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Corrupted by what?
--
Ian Collins.
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
MFC is off topic here as well as anything to do with "messaging". An
MFC class is not a C++ class either. The rule of thumb is: if it only
runs in Windows or only in Linux or whatever OS, its off topic here.
The language dealth with here is the C++ standard library.
Do yourself a big favour and consider WTL instead. What MFC should have
been in the first place.
It supports templates and inheritance. Its too bad that MS dropped
support for it, cause it rocks when compared to MFC. Last i checked, MS
remitted it to OpenSource under a dual-license. http://en.wikipedia.org/wiki/Windows_Template_Library
>
Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
return 1;
}
Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
As it is though, even C++ likes procedural main rather than some kind of
"program" class.
Please feel free to add any comments on tangential but associated topics
also.
Tony
"Salt_Peter" <pj*****@yahoo.comwrote in message
news:11*********************@e3g2000cwe.googlegrou ps.com...
>
Tony wrote:
>I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
MFC is off topic here as well as anything to do with "messaging". An
MFC class is not a C++ class either. The rule of thumb is: if it only
runs in Windows or only in Linux or whatever OS, its off topic here.
The language dealth with here is the C++ standard library.
It wasn't an MFC question at all. MFC was just the example. You clipped
too much of the original post that gave the context.
Tony
"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@mid.individual.net...
Tony wrote:
>I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
That doesn't add anything.
>What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Corrupted by what?
I don't know. I'm not a compiler writer. That's why I posted the question!
Perhaps
a guru answer would have addressed the issues surrounding combining data and
function and if that affects code robustness and how.
Tony
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
I acknowledge that it is not an MFC-exclusive question. But this isn't a
C++ language question either. This is all about library design.
>
Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
return 1;
}
Example 1 is clumsy. But this has nothing to do with C++. Go ask in an
MFC newsgroup why MFC handles messages like the above (although I
believe MFC was trying to hide both main()/WinMain() and the message
pumping loop from the user.)
>
Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
No comment.
>
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Again MFC's design philosophy isn't exactly what C++ is.
As it is though, even C++ likes procedural main rather than some kind of
"program" class.
What do you mean? C++ IS procedural, depending how you define "procedural".
>
Please feel free to add any comments on tangential but associated topics
also.
This post can be better responded in another newsgroup.
>
Tony
Ben
OT but ...
Every gui toolkit has something very similar class representing the
application and encapsulating the message loop
wxWidgets -wxApp
QT -QApplication
VCL -TApplication
and many many more...
All of them have a Run() method.
Its the way things are done....
And I dont get whats less "robust" about this.
Tony wrote:
"Salt_Peter" <pj*****@yahoo.comwrote in message
news:11*********************@e3g2000cwe.googlegrou ps.com...
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
MFC is off topic here as well as anything to do with "messaging". An
MFC class is not a C++ class either. The rule of thumb is: if it only
runs in Windows or only in Linux or whatever OS, its off topic here.
The language dealth with here is the C++ standard library.
It wasn't an MFC question at all. MFC was just the example. You clipped
too much of the original post that gave the context.
Tony
I didn't clip anything, and i can perhaps mention the following.
Although it is OT.
MyProg is basicly the equivalent of an application struct, which has
the capacity of storing handles to windows. Remember that a window is
not neccessarily a visible frame. A window is a targetable msg reciever
(it has a handle). So in the event that you need to send a message
directly to a window (as opposed to posting messages throughout the
window hierarchy), you'ld rather have Run() loop away the messages and
reroute with MyProg object's stored handles if you choose to. Also, in
the event you chose to spawn a thread to "run" the program, again using
the Run() member function will leave you with that option.
Now, as far as class robustness is concerned. How you protect your
encapsulated members and how you apply your const qualifiers is what
will decide if the class is robust. Needless to say, const is crucial
in C++ at every level. Any member function that is non-static and does
not modify the class should be const ( void MyProg::foo() const ). Any
member that is not volatile should be const. Parameters should
preferably be const references (something MFC balks at more often than
not). Whether you Run() in MyProg or loop in main() isn't going to
change those needs.
The problem here is that you are using MFC which is really C with a
pseudo-virtual mechanism with old style C function overrides and
pointers galore, which means that underneath all those overriden
functions, there is a implementation running that is hidden from you
and which you really can't do much about.
C++ classes tend to be much simpler in design than MFC "classes" with
security as the primary objective. You can't even pass void* around.
Its typical to program thousands of lines without ever using a single
pointer (except perhaps for smart pointers). So to disscuss robustness
with an implementation like MFC, which is nothing *but* loose pointers
is an oxymoron.
Here is a good example. Consider something ridiculous like:
int n;
const int* p_n = &n;
Is that a safe pointer? no its not, the value at the pointer is const
but the pointer itself can be changed!!!
int const * const p_n(&n); // ah !!!
p_n is now a constant pointer to a const integer. Yet nowhere will you
see that in MFC, which is a shame. That const pointer is nuke proof
until destruction - read it is all you can do. It basicly behaves like
a const reference after its initialized.
Use Run() since its static anyways (does not have a *this to the
object). You can let main() deal with exceptions, for example. What
i'ld suggest is learn how to encapsulate the class members and
functions. Thats always worth the trouble.
"Tony" <rd**************@sbcglobal.netwrote in message
news:Z0******************@newssvr12.news.prodigy.c om...
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
"Less" robust? Sounds more robust to me. It hides the implementation
details inside the class, so if the system requirements change, the change
can be made inside the class itself. Pretty common, if you ask me.
Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
Why not?
return 1;
}
Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code.
Corrupted by what? I don't understand the question. Classes are the heart
of object-oriented programming. If they were less stable or reliable than
procedural code, nobody would use them, and C++ would vanish.
Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
As it is though, even C++ likes procedural main rather than some kind of
"program" class.
What do you mean that C++ "likes procedural main"? The language couldn't
care less whether you do all your work in main or in global functions or in
classes.
It sounds as if you're suggesting removing main in favor of some kind of
global application class here. But how would other languages interact with
such a C++ class?
I think you're just worrying about nothing.
-Howard
Howard wrote:
"Tony" <rd**************@sbcglobal.netwrote in message
news:Z0******************@newssvr12.news.prodigy.c om...
>I'm working with GUI messaging and note that MFC encapsulates
[..]
[..]
I think you're just worrying about nothing.
I think he's just trolling.
"Salt_Peter" <pj*****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
>
Tony wrote:
>"Salt_Peter" <pj*****@yahoo.comwrote in message
news:11*********************@e3g2000cwe.googlegro ups.com...
>
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
MFC is off topic here as well as anything to do with "messaging". An
MFC class is not a C++ class either. The rule of thumb is: if it only
runs in Windows or only in Linux or whatever OS, its off topic here.
The language dealth with here is the C++ standard library.
It wasn't an MFC question at all. MFC was just the example. You clipped
too much of the original post that gave the context.
Tony
I didn't clip anything, and i can perhaps mention the following.
Although it is OT.
MyProg is basicly the equivalent of an application struct, which has
the capacity of storing handles to windows. Remember that a window is
not neccessarily a visible frame. A window is a targetable msg reciever
(it has a handle). So in the event that you need to send a message
directly to a window (as opposed to posting messages throughout the
window hierarchy), you'ld rather have Run() loop away the messages and
reroute with MyProg object's stored handles if you choose to. Also, in
the event you chose to spawn a thread to "run" the program, again using
the Run() member function will leave you with that option.
Now, as far as class robustness is concerned. How you protect your
encapsulated members and how you apply your const qualifiers is what
will decide if the class is robust. Needless to say, const is crucial
in C++ at every level. Any member function that is non-static and does
not modify the class should be const ( void MyProg::foo() const ). Any
member that is not volatile should be const. Parameters should
preferably be const references (something MFC balks at more often than
not). Whether you Run() in MyProg or loop in main() isn't going to
change those needs.
The problem here is that you are using MFC which is really C with a
pseudo-virtual mechanism with old style C function overrides and
pointers galore, which means that underneath all those overriden
functions, there is a implementation running that is hidden from you
and which you really can't do much about.
C++ classes tend to be much simpler in design than MFC "classes" with
security as the primary objective. You can't even pass void* around.
Its typical to program thousands of lines without ever using a single
pointer (except perhaps for smart pointers). So to disscuss robustness
with an implementation like MFC, which is nothing *but* loose pointers
is an oxymoron.
Here is a good example. Consider something ridiculous like:
int n;
const int* p_n = &n;
Is that a safe pointer? no its not, the value at the pointer is const
but the pointer itself can be changed!!!
int const * const p_n(&n); // ah !!!
p_n is now a constant pointer to a const integer. Yet nowhere will you
see that in MFC, which is a shame. That const pointer is nuke proof
until destruction - read it is all you can do. It basicly behaves like
a const reference after its initialized.
Use Run() since its static anyways (does not have a *this to the
object). You can let main() deal with exceptions, for example. What
i'ld suggest is learn how to encapsulate the class members and
functions. Thats always worth the trouble.
Well I really wanted to know about the issue from a lower level
perspective than at the programming level That is, what happens at
the compiler level that could have some relevance. Why doesn't
C++ provide a Prog class with a main member function for example?
Apparently, a number of people think that the main program flow
belongs in a main() function rather than a class method.
BTW, I'm not actually using MFC, just looking it over. I was really
concerned about my example rather than MFC, since mine illustrates
the issue (that MFC makes Run() a static method may have relevance
though: they didn't think making Run() part of a C++ class was appropriate
either). I wasn't actually looking at the MFC code, but rather someone
else's class doc that mentioned the MFC Run() "encapsulation" and that
didn't
mention that it was defined static. So... the question seems even more
relevant now: why is it not good to put the message loop in a C++ member
function?
Tony
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45**********************@news.optusnet.com.au ...
Tony wrote:
>I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
I acknowledge that it is not an MFC-exclusive question. But this isn't a
C++ language question either. This is all about library design.
No, not really. The question is really why a C-style main() function is used
in C++ programs exclusively rather than some class object with a main()
method. Apparently people think that the latter is a bad idea, but I'm
wondering
why exactly.
>Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
return 1;
}
Example 1 is clumsy. But this has nothing to do with C++. Go ask in an MFC
newsgroup why MFC handles messages like the above (although I believe MFC
was trying to hide both main()/WinMain() and the message pumping loop from
the user.)
It's just an example that illustrates a case where the main program flow
would execute in a class function. The question was a C++ one and not at
all about MFC or even what the example is doing, as that is not really
important.
>Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
No comment.
>>
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Again MFC's design philosophy isn't exactly what C++ is.
MFC is not at all part of the question.
>As it is though, even C++ likes procedural main rather than some kind of
"program" class.
What do you mean? C++ IS procedural, depending how you define
"procedural".
As in the example 2 above.
>Please feel free to add any comments on tangential but associated topics
also.
This post can be better responded in another newsgroup.
Perhaps: those with low level implementation knowledge of C++ compilers.
Tony
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:ej**********@news.datemas.de...
Howard wrote:
>"Tony" <rd**************@sbcglobal.netwrote in message
news:Z0******************@newssvr12.news.prodigy. com...
>>I'm working with GUI messaging and note that MFC encapsulates
[..]
[..]
I think you're just worrying about nothing.
I think he's just trolling.
That's your world/game perhaps, not mine.
"Howard" <al*****@hotmail.comwrote in message
news:FS******************@bgtnsc05-news.ops.worldnet.att.net...
>
"Tony" <rd**************@sbcglobal.netwrote in message
news:Z0******************@newssvr12.news.prodigy.c om...
>I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
"Less" robust? Sounds more robust to me. It hides the implementation
details inside the class, so if the system requirements change, the change
can be made inside the class itself. Pretty common, if you ask me.
Very UNCOMMON for the main program flow. Note that C++ defines no
Program class or some such thing to do things OO from the get go rather than
the C-style main() way.
>Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
Why not?
I don't know! Probably because no one (?) else does it that way.
>
> return 1;
}
Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code.
Corrupted by what? I don't understand the question. Classes are the
heart of object-oriented programming. If they were less stable or
reliable than procedural code, nobody would use them, and C++ would
vanish.
I'm not sure by what. Why doesn't C++ have perhaps an optional way of
starting into a program rather than just main()? Just instantiate a Program
class object or something like that. Sounds even worse: the program would
run in an object constructor!
>
>Perhaps if C++ went "all the way" and eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
As it is though, even C++ likes procedural main rather than some kind of
"program" class.
What do you mean that C++ "likes procedural main"?
Bad choice of word "procedural". I meant, why main() rather than some kind
of class object instance?
The language couldn't care less whether you do all your work in main or in
global functions or in classes.
I know it'll work. But it seems bizarre to do something like that.
>
It sounds as if you're suggesting removing main in favor of some kind of
global application class here.
Not suggesting, just wondering why.
But how would other languages interact with such a C++ class?
As if they can interact with main()?
I think you're just worrying about nothing.
Just curious.
Tony
Wow, a lot of people in here see a message loop example and
completely disregard the content of the question being asked.
Focus people. Focus.
Tony
"rep_movsd" <re*******@gmail.comwrote in message
news:11**********************@h54g2000cwb.googlegr oups.com...
>
OT but ...
Every gui toolkit has something very similar class representing the
application and encapsulating the message loop
wxWidgets -wxApp
QT -QApplication
VCL -TApplication
and many many more...
All of them have a Run() method.
Its the way things are done....
And I dont get whats less "robust" about this.
Firstly, the question is perfectly on topic.
The answer is that neither is more robust, however it is usually
poor practice to create an object just to call a member function,
which is what is being done here. There is no object-oriented
functionality; the member function is being called just for its side
effects, it does not manipulate any data members of the object.
In this situation, a much better approach is to use a plain (global)
function, and if necessary put it in a namespace to achieve
encapsulation.
Steve
Tony wrote:
I'm not sure by what. Why doesn't C++ have perhaps an optional way of
starting into a program rather than just main()? Just instantiate a Program
class object or something like that. Sounds even worse: the program would
run in an object constructor!
Because there is no reason to do it that way. C++ is a multi-paradigm
language. If the best solution to a problem is object oriented, then
C++ can handle that. If the best solution is procedural, then C++ can
handle that too. C++ even has a few functional elements (especially if
you consider TMP). With the way things currently are, if a programmer
wants to model his entire application as an object, C++ makes it
trivially easy to do that.
A more pragmatic reason might be that there is some effort spent on
trying to maintain compatibility with C. If you were forced to model
an application as an object, then C programs could no longer be
compiled with a C++ compiler.
--
Alan Johnson
Tony wrote:
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45**********************@news.optusnet.com.au ...
>Tony wrote:
>>I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
I acknowledge that it is not an MFC-exclusive question. But this isn't a
C++ language question either. This is all about library design.
No, not really. The question is really why a C-style main() function is used
in C++ programs exclusively rather than some class object with a main()
method. Apparently people think that the latter is a bad idea, but I'm
wondering
why exactly.
Because putting the main function in a class just doesn't make any
sense. Why would you want to do that? And what do you get from doing that?
>
>>Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a class
func
return 1;
}
Example 1 is clumsy. But this has nothing to do with C++. Go ask in an MFC
newsgroup why MFC handles messages like the above (although I believe MFC
was trying to hide both main()/WinMain() and the message pumping loop from
the user.)
It's just an example that illustrates a case where the main program flow
would execute in a class function. The question was a C++ one and not at
all about MFC or even what the example is doing, as that is not really
important.
Still I don't see the question. What's wrong?
>>Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
No comment.
>>What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Again MFC's design philosophy isn't exactly what C++ is.
MFC is not at all part of the question.
>>As it is though, even C++ likes procedural main rather than some kind of
"program" class.
What do you mean? C++ IS procedural, depending how you define
"procedural".
As in the example 2 above.
>>Please feel free to add any comments on tangential but associated topics
also.
This post can be better responded in another newsgroup.
Perhaps: those with low level implementation knowledge of C++ compilers.
This has got nothing to do with low level implementation of C++. It is a
design question. C++ is designed to have a standalone main() function as
an entry point and programs written in C++ adapts to that fact.
>
Tony
Ben
Tony:
No, not really. The question is really why a C-style main() function is
used in C++ programs exclusively rather than some class object with a
main() method. Apparently people think that the latter is a bad idea,
but I'm wondering
why exactly.
As you know, in C++, we try to make our code as inefficient as possible. No,
actually, we try to make our code look as "modern" as possible, and one side-
effect is that it comes out inefficient.
Of course, to make our code even more modern, we'll have to start using:
class Program {
public:
static int main()
{
}
};
Then we'll just be a small step away from Java.
--
Frederick Gotham
Tony wrote:
>
I'm not sure by what. Why doesn't C++ have perhaps an optional way of
starting into a program rather than just main()? Just instantiate a Program
class object or something like that. Sounds even worse: the program would
run in an object constructor!
Actually, I've seen (in the early days), programs that did exactly that.
Some primitive CUI frameworks actually did all the work out of the
constuctor for a global "App" object, and main() was an empty function.
Tony wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@mid.individual.net...
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
That doesn't add anything.
C++ needs to maintain backwards compatability with C, at least to the
point that it can compile 99% of C programs out there. C had no
objects, thus it had a global main function as an entry point. So C++
has one too.
Note that when you're talking about frameworks, this requirement goes
away. Object-based frameworks cannot jive with C, so there's no need to
keep the old C linkage in place.
What I'm thinking about is whether a class is more likely to be corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Corrupted by what?
I don't know. I'm not a compiler writer. That's why I posted the question!
Perhaps
a guru answer would have addressed the issues surrounding combining data and
function and if that affects code robustness and how.
The way you're talking about classes is a little silly. There no
meaning to "combining data and function", this concept only exists at
compile time. After it's all been compiled, data and code work pretty
much the same way they do in compiled C code. They live in their
separate areas of memory (segments / sections / pages / whatever) and
independantly do their own thing. Objects don't just spontaneously get
corrupted, if anything less memory corruption occurs in C++ due to
libraries with buffer checking.
If you're really interested in learning how it really works underneath
the hood, here's a good start: [ http://www.programmers-corner.com/tutorial/36 ]. Note that this is only
one possible implementation technique, and thus is compiler-specific /
environment-specific / os-specific / day-of-the-week-specific and
therefore undefined and off topic.
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45***********************@news.optusnet.com.a u...
Tony wrote:
>"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45**********************@news.optusnet.com.a u...
>>Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
I acknowledge that it is not an MFC-exclusive question. But this isn't a
C++ language question either. This is all about library design.
No, not really. The question is really why a C-style main() function is
used
in C++ programs exclusively rather than some class object with a main()
method. Apparently people think that the latter is a bad idea, but I'm
wondering
why exactly.
Because putting the main function in a class just doesn't make any sense.
Why would you want to do that? And what do you get from doing that?
Just looking for an OO approach from the get go. It could give entire
program
specialization through inheretitance perhaps. As it stands frameworks fake
this approach so maybe some attempt to embrace it as fundamental would be
appropriate. It may also make programming more accessible by making things
easier to comprehend (no need to program in a multi-paradigmic way).
>>>Example 1:
class MyProg
{
public:
void Run()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
}
};
int main()
{
MyProg p;
p.Run(); // just doesn't feel right to run the whole prog in a
class func
return 1;
}
Example 1 is clumsy. But this has nothing to do with C++. Go ask in an
MFC newsgroup why MFC handles messages like the above (although I
believe MFC was trying to hide both main()/WinMain() and the message
pumping loop from the user.)
It's just an example that illustrates a case where the main program flow
would execute in a class function. The question was a C++ one and not at
all about MFC or even what the example is doing, as that is not really
important.
Still I don't see the question. What's wrong?
>>>Example 2:
int main()
{
Msg m;
while(GetMsg(m))
DispatchMsg(m);
return 1;
}
No comment.
What I'm thinking about is whether a class is more likely to be
corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated message
loop.
Again MFC's design philosophy isn't exactly what C++ is.
MFC is not at all part of the question.
>>>As it is though, even C++ likes procedural main rather than some kind
of
"program" class.
What do you mean? C++ IS procedural, depending how you define
"procedural".
As in the example 2 above.
>>>Please feel free to add any comments on tangential but associated
topics also.
This post can be better responded in another newsgroup.
Perhaps: those with low level implementation knowledge of C++ compilers.
This has got nothing to do with low level implementation of C++. It is a
design question. C++ is designed to have a standalone main() function as
an entry point and programs written in C++ adapts to that fact.
It's directly associated with the design and implementation of C++ and
perhaps
its evolution.
Tony
<du*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...
>
Tony wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@mid.individual.net...
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
That doesn't add anything.
C++ needs to maintain backwards compatability with C, at least to the
point that it can compile 99% of C programs out there. C had no
objects, thus it had a global main function as an entry point. So C++
has one too.
I could have an alternative paradigm also though. One more aligned with
the OO side of things. C++ a multi-paradigm language? Yes. But can one
program to one paradigm or the other exclusively? Well apparently not
OO from the get go surely (main() required, and nothing OO about that).
>
Note that when you're talking about frameworks, this requirement goes
away. Object-based frameworks cannot jive with C, so there's no need to
keep the old C linkage in place.
>What I'm thinking about is whether a class is more likely to be
corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated
message
loop.
Corrupted by what?
I don't know. I'm not a compiler writer. That's why I posted the
question!
Perhaps
a guru answer would have addressed the issues surrounding combining data
and
function and if that affects code robustness and how.
The way you're talking about classes is a little silly. There no
meaning to "combining data and function", this concept only exists at
compile time.
Well there's a lot more going on under the hood, vtables and other stuff.
So just the fact that it is more complex under the hood may have some
relevance.
After it's all been compiled, data and code work pretty
much the same way they do in compiled C code. They live in their
separate areas of memory (segments / sections / pages / whatever) and
independantly do their own thing. Objects don't just spontaneously get
corrupted, if anything less memory corruption occurs in C++ due to
libraries with buffer checking.
If you're really interested in learning how it really works underneath
the hood, here's a good start: [
http://www.programmers-corner.com/tutorial/36 ]. Note that this is only
one possible implementation technique, and thus is compiler-specific /
environment-specific / os-specific / day-of-the-week-specific and
therefore undefined and off topic.
I'd actually be more interested in knowing why my example 2 is preferred
by most over example 1 (from what has been said, MFC makes its Run()
function static). Heck, why not make a Program class and put the Run()
functionality (a message loop for EXAMPLE) in the constructor and do
clean up in the destructor?
Tony
>
"Alan Johnson" <aw***@yahoo.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...
Tony wrote:
>I'm not sure by what. Why doesn't C++ have perhaps an optional way of
starting into a program rather than just main()? Just instantiate a
Program
class object or something like that. Sounds even worse: the program would
run in an object constructor!
Because there is no reason to do it that way. C++ is a multi-paradigm
language.
Well the casual observer would think that means that one can program
exclusively in one paradigm. Unfortunately in C++ that is not true. One
MUST program multi-paradigmically in C++.
If the best solution to a problem is object oriented, then
C++ can handle that.
Not exclusively. Not from the get go.
If the best solution is procedural, then C++ can
handle that too.
Granted, that it can. It's slanted toward procedural rather than OO (if one
weighs the program entry point more heavily perhaps).
C++ even has a few functional elements (especially if
you consider TMP). With the way things currently are, if a programmer
wants to model his entire application as an object, C++ makes it
trivially easy to do that.
Actually, it doesn't! (main() is required and it is procedural).
A more pragmatic reason might be that there is some effort spent on
trying to maintain compatibility with C. If you were forced to model
an application as an object, then C programs could no longer be
compiled with a C++ compiler.
Well no one was suggesting forcing anything. Currently one is forced to
program multi-paradigmically. Adding an alternative OO approach that
replaces main() at a low level (not just wrapping it) would allow
an OO approach exclusive of the procedural paradigm (and probably
open up a number of other possibilities).
Tony
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:eE*******************@news.indigo.ie...
Tony:
>No, not really. The question is really why a C-style main() function is
used in C++ programs exclusively rather than some class object with a
main() method. Apparently people think that the latter is a bad idea,
but I'm wondering
why exactly.
As you know, in C++, we try to make our code as inefficient as possible.
No,
actually, we try to make our code look as "modern" as possible, and one
side-
effect is that it comes out inefficient.
Of course, to make our code even more modern, we'll have to start using:
class Program {
public:
static int main()
{
}
};
Then we'll just be a small step away from Java.
Perhaps the perceived inefficiency of doing the Program::Run() thing is why
it's not a low level C++ construct.
Tony
"Steve Pope" <sp*****@speedymail.orgwrote in message
news:ej**********@blue.rahul.net...
Firstly, the question is perfectly on topic.
The answer is that neither is more robust, however it is usually
poor practice to create an object just to call a member function,
which is what is being done here. There is no object-oriented
functionality; the member function is being called just for its side
effects, it does not manipulate any data members of the object.
Surely a real class would have data members to "manipulate" though.
It's just an example to point out the corresponding paradigms.
In this situation, a much better approach is to use a plain (global)
function, and if necessary put it in a namespace to achieve
encapsulation.
Tony
"red floyd" <no*****@here.dudewrote in message
news:Uz******************@newssvr12.news.prodigy.c om...
Tony wrote:
>>
I'm not sure by what. Why doesn't C++ have perhaps an optional way of
starting into a program rather than just main()? Just instantiate a
Program
class object or something like that. Sounds even worse: the program would
run in an object constructor!
Actually, I've seen (in the early days), programs that did exactly that.
Some primitive CUI frameworks actually did all the work out of the
constuctor for a global "App" object, and main() was an empty function.
And that thought of course is where this thread started.
Tony
Tony <rd**************@sbcglobal.netwrote:
>"Steve Pope" <sp*****@speedymail.orgwrote in message
>The answer is that neither is more robust, however it is usually
poor practice to create an object just to call a member function,
which is what is being done here. There is no object-oriented
functionality; the member function is being called just for its side
effects, it does not manipulate any data members of the object.
>Surely a real class would have data members to "manipulate" though.
It's just an example to point out the corresponding paradigms.
I agree, but then the example is lacking in essential details. I can
only comment on the code that was posted. A class does not
make sense in this case. "When to use a class" is an important
concept in C++.
Steve
Tony wrote:
<du*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...
Tony wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@mid.individual.net...
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
That doesn't add anything.
C++ needs to maintain backwards compatability with C, at least to the
point that it can compile 99% of C programs out there. C had no
objects, thus it had a global main function as an entry point. So C++
has one too.
I could have an alternative paradigm also though. One more aligned with
the OO side of things. C++ a multi-paradigm language? Yes. But can one
program to one paradigm or the other exclusively? Well apparently not
OO from the get go surely (main() required, and nothing OO about that).
This has nothing to do with paradigms or exclusivity. The reason C++
programs begin running at a "main" function is historical. C++ was
originally just a front end preprocessor that spit out C code. It
wasn't designed as object-oriented from the ground-up. C++ is *not*
Java.
Note that when you're talking about frameworks, this requirement goes
away. Object-based frameworks cannot jive with C, so there's no need to
keep the old C linkage in place.
What I'm thinking about is whether a class is more likely to be
corrupted
than the equivalent C code. Perhaps if C++ went "all the way" and
eliminated
the C main function I'd feel better with the class-encapsulated
message
loop.
Corrupted by what?
I don't know. I'm not a compiler writer. That's why I posted the
question!
Perhaps
a guru answer would have addressed the issues surrounding combining data
and
function and if that affects code robustness and how.
The way you're talking about classes is a little silly. There no
meaning to "combining data and function", this concept only exists at
compile time.
Well there's a lot more going on under the hood, vtables and other stuff.
So just the fact that it is more complex under the hood may have some
relevance.
After it's all been compiled, data and code work pretty
much the same way they do in compiled C code. They live in their
separate areas of memory (segments / sections / pages / whatever) and
independantly do their own thing. Objects don't just spontaneously get
corrupted, if anything less memory corruption occurs in C++ due to
libraries with buffer checking.
If you're really interested in learning how it really works underneath
the hood, here's a good start: [
http://www.programmers-corner.com/tutorial/36 ]. Note that this is only
one possible implementation technique, and thus is compiler-specific /
environment-specific / os-specific / day-of-the-week-specific and
therefore undefined and off topic.
I'd actually be more interested in knowing why my example 2 is preferred
by most over example 1 (from what has been said, MFC makes its Run()
function static). Heck, why not make a Program class and put the Run()
functionality (a message loop for EXAMPLE) in the constructor and do
clean up in the destructor?
Tony
I believe MFC is also doing a bunch of additional prologue and epilogue
code within the framework, before and after your "Run" function using
inheritance. But regardless, I'm sure we all agree MFC is just plain
silly.
"Steve Pope" <sp*****@speedymail.orgwrote in message
news:ej**********@blue.rahul.net...
Tony <rd**************@sbcglobal.netwrote:
>>"Steve Pope" <sp*****@speedymail.orgwrote in message
>>The answer is that neither is more robust, however it is usually
poor practice to create an object just to call a member function,
which is what is being done here. There is no object-oriented
functionality; the member function is being called just for its side
effects, it does not manipulate any data members of the object.
>>Surely a real class would have data members to "manipulate" though.
It's just an example to point out the corresponding paradigms.
I agree, but then the example is lacking in essential details. I can
only comment on the code that was posted. A class does not
make sense in this case. "When to use a class" is an important
concept in C++.
Read the whole post/thread from the beginning and you'll comprehend
(hopefully) what the "issue" is. It's a high level C++ language design
and implementation question rather than a textbook programming puzzle.
Tony
<du*****@gmail.comwrote in message
news:11********************@f16g2000cwb.googlegrou ps.com...
>
Tony wrote:
><du*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googleg roups.com...
>
Tony wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@mid.individual.net...
Tony wrote:
I'm working with GUI messaging and note that MFC encapsulates
the message loop inside of a C++ class member function. Is this
somehow inherently less robust than calling the message loop
functions within main? (It just doesn't "feel" right to me).
Does anything in MFC feel right?
That doesn't add anything.
C++ needs to maintain backwards compatability with C, at least to the
point that it can compile 99% of C programs out there. C had no
objects, thus it had a global main function as an entry point. So C++
has one too.
I could have an alternative paradigm also though. One more aligned with
the OO side of things. C++ a multi-paradigm language? Yes. But can one
program to one paradigm or the other exclusively? Well apparently not
OO from the get go surely (main() required, and nothing OO about that).
This has nothing to do with paradigms or exclusivity. The reason C++
programs begin running at a "main" function is historical. C++ was
originally just a front end preprocessor that spit out C code. It
wasn't designed as object-oriented from the ground-up. C++ is *not*
Java.
I made a typo: 'I' should have been 'It'. Again, you are assuming that it
has to
be one or the other. Apparently you have a paradigm!
(Aside: 'paradigm' is by definition "bad". We (I) use it more loosely than
that
but indeed when one starts thinking outside the box in a programming
language
group, the term 'paradigm' seems real appropriate (!)).
I believe MFC is also doing a bunch of additional prologue and epilogue
code within the framework, before and after your "Run" function using
inheritance. But regardless, I'm sure we all agree MFC is just plain
silly.
I _had_ to use it 10 years ago on a project. I wouldn't touch it with a
10-ft
pole in my own work though. It's not that MFC is inherently bad, it's that
the underlying API is "bad"! (OK, so they could have chosen to abstract
the uglies rather than the "thin veneer" approach).
My question wasn't about MFC though.
Tony
I believe MFC is also doing a bunch of additional prologue and epilogue
code within the framework, before and after your "Run" function using
inheritance. But regardless, I'm sure we all agree MFC is just plain
silly.
What's silly is making such blanket statements. We certainly don't "all"
agree.
If you don't like it, fine. Don't use it. But let's try to keep the
discussions about the C++ language, and not about personal opinions on
third-party products.
-Howard
Howard wrote:
I believe MFC is also doing a bunch of additional prologue and epilogue
code within the framework, before and after your "Run" function using
inheritance. But regardless, I'm sure we all agree MFC is just plain
silly.
What's silly is making such blanket statements. We certainly don't "all"
agree.
If you don't like it, fine. Don't use it. But let's try to keep the
discussions about the C++ language, and not about personal opinions on
third-party products.
-Howard
Sorry for the levity. I didn't mean to offend your personal tastes.
Tony <rd**************@sbcglobal.netwrote:
>"Steve Pope" <sp*****@speedymail.orgwrote in message
>Tony <rd**************@sbcglobal.netwrote:
>>>"Steve Pope" <sp*****@speedymail.orgwrote in message
>>>The answer is that neither is more robust, however it is usually
poor practice to create an object just to call a member function,
which is what is being done here. There is no object-oriented
functionality; the member function is being called just for its side
effects, it does not manipulate any data members of the object.
>>>Surely a real class would have data members to "manipulate" though.
It's just an example to point out the corresponding paradigms.
>I agree, but then the example is lacking in essential details. I can
only comment on the code that was posted. A class does not
make sense in this case. "When to use a class" is an important
concept in C++.
>Read the whole post/thread from the beginning and you'll comprehend
(hopefully) what the "issue" is.
I always read an entire thread before posting to it.
I was commenting on (1) your original question of whether or
not to use a class in this case and (2) Howard's comment that
it is better to use a class, due to the encapsulation; I disagree
with that (for the reason I described above).
You then went on to ask some other questions ("Why does C++ use
main()") which I chose not to address because the discussion
there was fairly complete. But since nobody had (yet) made
the observation that a namespace rather than a class is the
correct encapsulation method for the example given, I thought
I'd point that out.
Steve
Frederick Gotham wrote:
Tony:
>No, not really. The question is really why a C-style main() function is
used in C++ programs exclusively rather than some class object with a
main() method. Apparently people think that the latter is a bad idea,
but I'm wondering
why exactly.
As you know, in C++, we try to make our code as inefficient as possible. No,
actually, we try to make our code look as "modern" as possible, and one side-
effect is that it comes out inefficient.
Of course, to make our code even more modern, we'll have to start using:
class Program {
public:
static int main()
{
}
};
Then we'll just be a small step away from Java.
Seriously, what's the difference? Your Program class is nothing but a
glorified plain main().
On the other hand, libraries, especially GUI libraries typically
provides a class that many people mistakenly suppose to represent the
whole program. And such a class typically provides member functions like
Run() or main() etc.
But we must see that the nature of all GUI application involves some
sort of event handling, which is typically done with querying events
from a loop. A good GUI library should provide an abstraction beyond the
detail of repeatedly query (or pumping) these events and the best way to
do it is to hide the looping code away from the user with the
application class.
And that has nothing to do with low level implementation of C++, nor the
C++ language per se.
Regards,
Ben
Perhaps the perceived inefficiency of doing the Program::Run() thing is why
it's not a low level C++ construct.
Tony
What do you mean by "low level C++ construct"? A static class member
function is just as efficient as a standalone function. A non-static
class member is the same as the standalone counterpart with an extra
expense of passing and additional this pointer, which is minimum.
After a long post history I still don't quite get your intention. So
I'll just rephrase what I think your question is:
Why a C++ program's entry point is the global
int main();
instead of, say,
class C
{
int main(){}
};
?
If the above is indeed your questions then the answer is because the
former is cleaner, minimum, C-compatible, and can be used to facilitate
the latter.
Ben
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45***********************@news.optusnet.com.a u...
Frederick Gotham wrote:
>Tony:
>>No, not really. The question is really why a C-style main() function is
used in C++ programs exclusively rather than some class object with a
main() method. Apparently people think that the latter is a bad idea,
but I'm wondering
why exactly.
As you know, in C++, we try to make our code as inefficient as possible.
No, actually, we try to make our code look as "modern" as possible, and
one side-
effect is that it comes out inefficient.
Of course, to make our code even more modern, we'll have to start using:
class Program {
public:
static int main()
{
}
};
Then we'll just be a small step away from Java.
Seriously, what's the difference? Your Program class is nothing but a
glorified plain main().
Indeed. Since it is static, it's exactly the same. Nothing OO about that.
It's
an encapsulation of the idiosynchrasies of the C paradigm (emphasis on
'paradigm').
On the other hand, libraries, especially GUI libraries typically provides
a class that many people mistakenly suppose to represent the whole
program.
That's not necessarily bad. Should/could there be such semantics and can
those semantics reflect the machine and environment even better?
And such a class typically provides member functions like Run() or main()
etc.
But we must see that the nature of all GUI application involves some sort
of event handling, which is typically done with querying events from a
loop. A good GUI library should provide an abstraction beyond the detail
of repeatedly query (or pumping) these events and the best way to do it is
to hide the looping code away from the user with the application class.
And that has nothing to do with low level implementation of C++, nor the
C++ language per se.
Well it does in that it is one type of program. Perhaps a reanalysis of what
a program is, is in order (where now "program" means "C program").
Tony
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45***********************@news.optusnet.com.a u...
>Perhaps the perceived inefficiency of doing the Program::Run() thing is
why
it's not a low level C++ construct.
Tony
What do you mean by "low level C++ construct"?
Some kind of replacement for main().
A static class member function is just as efficient as a standalone
function. A non-static class member is the same as the standalone
counterpart with an extra expense of passing and additional this pointer,
which is minimum.
After a long post history I still don't quite get your intention. So I'll
just rephrase what I think your question is:
Why a C++ program's entry point is the global
int main();
instead of, say,
class C
{
int main(){}
};
?
If the above is indeed your questions then the answer is because the
former is cleaner, minimum, C-compatible, and can be used to facilitate
the latter.
The former is procedural though and probably hard to grasp for someone
learning how to program and using the OO paradigm. 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).
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, 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.
Tony
>After a long post history I still don't quite get your intention. So I'll
>just rephrase what I think your question is:
Why a C++ program's entry point is the global
int main();
instead of, say,
class C
{
int main(){}
};
?
If the above is indeed your questions then the answer is because the
former is cleaner, minimum, C-compatible, and can be used to facilitate
the latter.
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.
>
Tony
Ben
Tony:
Perhaps the perceived inefficiency of doing the Program::Run() thing is
why it's not a low level C++ construct.
Actually, I was mocking what I deem to be a stupid attitude.
"main" is a perfect candidate for a function. The only reason anyone would
want to make some sort of class out of it is so they can, "hmm... look,
everything's object orientated, I can do Java me."
--
Frederick Gotham
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45***********************@news.optusnet.com.a u...
>>After a long post history I still don't quite get your intention. So
I'll just rephrase what I think your question is:
Why a C++ program's entry point is the global
int main();
instead of, say,
class C
{
int main(){}
};
?
If the above is indeed your questions then the answer is because the
former is cleaner, minimum, C-compatible, and can be used to facilitate
the latter.
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.
I'm not sure why so many people respond with thoughts constrained to "it
has to be one way or the other". Can you say major paradigm?
>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.
Well I hope someone will think outside of the box and post an alternative!
>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.
The point is that C++ supports procedural programming moreso than OO.
(Don't even get me started on the over-emphasis and over use of generic
programming!)
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.
If you're just getting started I guess they would be. Nice to review at
other
times too perhaps, but there's probably more interesting reads elsewhere
(like USENET maybe!).
Tony
[snip]
>
>On the other hand, libraries, especially GUI libraries typically provides
a class that many people mistakenly suppose to represent the whole
program.
That's not necessarily bad. Should/could there be such semantics and can
those semantics reflect the machine and environment even better?
From what I see and understand, whether the program starts with main()
or from a member function of a certain class, is trivial. C++ chooses
the plain old main() not to suppress OO, but to give you an opportunity
to specify how the program should start with while retaining
C-compatibility.
I have mentioned it many times, but perhaps I haven't made it clear. If
C++ does allow an alternate entry point of a program, let's say, a class
member function called upon an object that represents the environment
and state of the program from an OO point of view, then you at least
have to have some mechanism to specify what that entry point is in first
place.
You can view the main() function as exactly what you need: to specify
the alternate entry point. And this is indeed a very flexible way to do
so because just about any alternate entry point is possible. All that is
asking from you, is to give an alternate definition of "alternate entry
point".
Even the main() doesn't have to be the true entry point in a lot of
standard C++ programs. Global and namespace scope objects are
constructed even before the main().
BTW, though this is not that relevant to the point I just made, yet I
still want to stress that Object-Oriented programming (and even generic
programming) is procedure in nature. OOP, in my view, is a way to manage
data structure and procedures; and procedure is what directly controls
the flow of execution. Non-procedural programming is more like Prolog,
rather than Java/Smalltalk.
Regards,
Ben
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Jt*******************@news.indigo.ie...
Tony:
>Perhaps the perceived inefficiency of doing the Program::Run() thing is
why it's not a low level C++ construct.
Actually, I was mocking what I deem to be a stupid attitude.
"main" is a perfect candidate for a function. The only reason anyone would
want to make some sort of class out of it is so they can, "hmm... look,
everything's object orientated, I can do Java me."
Opinions are like... nevermind.
"benben" <benhonghatgmaildotcom@nospamwrote in message
news:45***********************@news.optusnet.com.a u...
[snip]
>>
>>On the other hand, libraries, especially GUI libraries typically
provides a class that many people mistakenly suppose to represent the
whole program.
That's not necessarily bad. Should/could there be such semantics and can
those semantics reflect the machine and environment even better?
From what I see and understand, whether the program starts with main() or
from a member function of a certain class, is trivial.
The solicitation was for presentation and discussion of alternatives rather
than any particular wrapping or alternative. People seem to be saying, "well
there's main() and we need to abstract that (or not!)" rather than saying
anything
new. Maybe it's something for the scientist level folks to chew on rather
than the
layman user/developer (though I do it anyway :)).
Tony This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: RageARC |
last post by:
I have the following code:
index.php:
class main_class {
public $database = new DAL;
public $html = new HTML;
}
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
