Class method less robust than C function?

[Tony]

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

 

[Ian Collins]

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?

 

[Salt_Peter]

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

 

[Tony]

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

 

[Tony]

Does anything in MFC feel right?

That doesn't add anything.

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

 

[benben]

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

 

[rep_movsd]

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.

 

[Salt_Peter]

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.

 

[Howard]

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

 

[Victor Bazarov]

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.

 

[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

 

[Tony]

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 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.

No comment.


Again MFC's design philosophy isn't exactly what C++ is.

MFC is not at all part of the question.

What do you mean? C++ IS procedural, depending how you define
"procedural".

As in the example 2 above.

This post can be better responded in another newsgroup.

Perhaps: those with low level implementation knowledge of C++ compilers.

Tony

 

[Tony]

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.

 

[Tony]

"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.

Why not?

I don't know! Probably because no one (?) else does it that way.

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!

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

 

[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

 

[Steve Pope]

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

 

[Alan Johnson]

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.

 

[benben]

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?

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?

MFC is not at all part of the question.


As in the example 2 above.


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

 

[Frederick Gotham]

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.

 

[red floyd]

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.