Class method less robust than C function?

[Tony]

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?

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!

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

 

[benben]

[snip]

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

 

[Tony]

Tony:



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.

 

[Tony]

[snip]

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