Too bad this can't be done

[sans-hubris]

#include <include>
using namespace std;

class Function {
public:
int operator() (void) { cout << "It worked!" << endl;
private:
} main;

<edit>bad ubb, bad ubb, sorry</edit>
And then have the OS just call main() since () was overloaded. That'd be cool. It'd be a way to make C++ completely OO.

[ 09 May 2001: Message edited by: ndogg.cpp ]

[BrianDrozd]

Umm...
You do realize that isn't how other complete object oriented languages do it, right? Not even smalltalk. All completely object oriented langauges have you define a function (main in Java, and it's been too long since I last saw Smalltalk to remember) that the program calls first. Then when the program is compiled (or, in Java's case, run), you specify which class has the "main" function. It is possible to write completely object-oriented code within C++.

[Energon]

How is it possible to write completely OO code in C++? You can't put main() inside of a class...

[BrianDrozd]

Originally posted by Energon:
<STRONG>How is it possible to write completely OO code in C++? You can't put main() inside of a class...</STRONG>

My mistake. It's been several years since I've actually writen a full blown C++ program. Most of the programming I wind up doing is object-oriented C code. Besides, main() could be writen like this:


int main(int argc, char ** argv)
{
SomeClass sc;
return sc.run(argc, argv);
}


Beyond that one function, which could be suitably buried in its own little file, the remainder could all be strict object-oreiented. But you are correct, it wouldn't be 'pure' object-oriented.

[Stuka]

Y'know, I'm really gettin' miffed by people who claim that to be "fully OO" all of the code in a language must be encapsulated in an object. The ONLY reason that Java gets away with this is because of the JVM, AFAIK. The main function in a C++ program is set up by the compiler to be the entry point for the OS. Java code simply has an entry point outside the compiled code - in the JVM. Now, is the JVM entry point wrapped in an object? I guess that depends on how the JVM is written, but my personal guess is that it isn't. Now, if I'm wrong, mea culpa...however, if I'm not, then &lt;rant&gt; All you "fully OO" Java snobs take that an' shove it up yer tailpipe!!! :mad:&lt;/rant&gt; Ok, I'm done now! :D

[sans-hubris]

Originally posted by Stuka:
<STRONG>Y'know, I'm really gettin' miffed by people who claim that to be "fully OO" all of the code in a language must be encapsulated in an object. The ONLY reason that Java gets away with this is because of the JVM, AFAIK. The main function in a C++ program is set up by the compiler to be the entry point for the OS. Java code simply has an entry point outside the compiled code - in the JVM. Now, is the JVM entry point wrapped in an object? I guess that depends on how the JVM is written, but my personal guess is that it isn't. Now, if I'm wrong, mea culpa...however, if I'm not, then &lt;rant&gt; All you "fully OO" Java snobs take that an' shove it up yer tailpipe!!! :mad:&lt;/rant&gt; Ok, I'm done now! :D</STRONG>

Actually, I agree with you (I'm not trying to conform, FYI), I was just thinking about how to make C++ completely OO for the heck of it.

[pinoy]

Having a main function inside a class does not exactly make it pure object oriented. If you look at Java, the main function is declared as static anyway, which means it could have just as well stood alone. It doesn't have real behavior like objects do.

The problem with C++ is its got too many paradigms. It supports structured, OO, generic, etc. Of course this is also one of its strength. To use C++ effectively, you probably need to use a combination of all paradigms. Look at STL, it's more oriented to generic programming than OO, and yet STL is part of Standard C++. C++ is not just OO.

OO is not all about encapsulation, which is what you are trying to suggest. OO's biggest strength is probably polymorphism (virtual functions in C++), which makes C a difficult language to use as OO (remember OO is just a paradigm). And for some people OO carries a lot of extra overhead. Sometimes it(OO) isn't typesafe, and just too many indirections to make a method call. This is where STL shines.

[kmj]

and just too many indirections to make a method call

I thought that was worth repeating. :D
Plus C++ really ties itself up sometimes when you're trying to fully follow object oriented design patterns. Java seems like it works better, but of course, I haven't used it enough to know that for sure.

[Energon]

couldn't you just write your own C++ compiler (maybe based off of gcc w/ C++ extensions) that looks for main() in a special class and defines it as the entry point instead of just a static function called main? I'm just trying to look at this as the fact that as OO as you make a C++ program, it's still just linear assembly code when you break it down (though I may be wrong with that assumption) and the only reason main() is used is so the compiler knows where to look (and the only reason it's that way in Java is to keep C++ programs happy)...

I just don't see anything special about main() if you have the capability to modify the compiler (though it is a stupid idea since you have to distribute your new compiler, but you get the idea)...

[sans-hubris]

Originally posted by Energon:
<STRONG>couldn't you just write your own C++ compiler (maybe based off of gcc w/ C++ extensions) that looks for main() in a special class and defines it as the entry point instead of just a static function called main? I'm just trying to look at this as the fact that as OO as you make a C++ program, it's still just linear assembly code when you break it down (though I may be wrong with that assumption) and the only reason main() is used is so the compiler knows where to look (and the only reason it's that way in Java is to keep C++ programs happy)...

I just don't see anything special about main() if you have the capability to modify the compiler (though it is a stupid idea since you have to distribute your new compiler, but you get the idea)...</STRONG>

Sure you could, but compilers are extremely complex pieces of software that often have to get down and dirty with assembly, and possibly machine code.

[Energon]

last I heard, any person who graduates with a CS degree should be able to write their own compiler... so somebody should be able to do it... just not those of us who just kinda go along for the ride until we get that degree... :)

[pinoy]

If you look at any Java code, the main function is not really closely tied to the object anyway, in fact it is not in an object. A typical Java class with main would look something like: (I'm very rusty on my Java so bear with me.)


class MyClass {
public void run()
{
System.out.println("I'm running");
}

public static void main(String args[])
{
// Note: we can't just call run, we
// actually have to create an object.
// much like C++. main is not actually
// part of the object, rather it is
// just encapsulated in this class because
// Java does not allow us to create functions
// outside of a class scope.

MyClass obj = new MyClass();
obj.run();
}
}



This is almost the same code as BrianDrozd posted above.

If you really want to get rid of main. You can write a framework that has main in, that would invoke some object's function. MFC does exactly this, you implement CWinApp, and it call the Run() method on it.


I'm just trying to look at this as the fact that as OO as you make a C++ program, it's still just linear assembly code when you break it down (though I may be wrong with that assumption) and the only reason main() is used is so the compiler knows where to look (and the only reason it's that way in Java is to keep C++ programs happy)...


The reason main() is there is because the loader expects this entry point. OO IMO is mostly polymorphism and C++ supports this very well.

Consider the typical example:

class Shape {
public:
virtual void draw() = 0;
};

class Square : public Shape;
class Triangle : public Shape;
class Circle : public Shape;

vector&lt;Shape&gt; shapes;
...
vector&lt;Shape&gt;::iterator iter = shapes.begin();
while (iter != shapes.end()) {
Shape& shape = *iter;
shape.draw();
}


The important fact here is that you can program at the shape level without having to deal with every different type of shapes. C++ does this very well. You can write a stand alone function (just like main) that takes objects and still be object oriented. For example a sorting function (you don't need a class for a sort function). Of course you also have to worry about good OO design and object interactions. There are lots of classic OO designs, and they're now usually documented as patterns.

For anyone who hasn't read The Design Patterns book by Erich Gamma, et al. I really recommend it. I think it conveys the true spirit of OO.

[sans-hubris]

Originally posted by Energon:
<STRONG>last I heard, any person who graduates with a CS degree should be able to write their own compiler... so somebody should be able to do it... just not those of us who just kinda go along for the ride until we get that degree... :)</STRONG>

You might be right about that because we have a required compilers course up here, so I'll be learning how to do that in a few years.

[Stuka]

Originally posted by Energon:
<STRONG> it's still just linear assembly code when you break it down (though I may be wrong with that assumption) and the only reason main() is used is so the compiler knows where to look (and the only reason it's that way in Java is to keep C++ programs happy)...</STRONG>

OK, simple fact: in today's current processors (Pentium/Athlon types at least) ALL of the assembly code is linear. Any nonlinearity in execution of assembly code is introduced inside the processor through logic that I don't currently understand :confused: However, linearity (as such) of code execution does not mean that the code cannot be designed in any procedural, OO, or functional paradigm you desire. Object Oriented Programming is a way to design code - in the end, all the code, be it Java, C/C++, Perl, Python, Ruby, Visual Basic :o, Fortran, ADA, COBOL, or anything else, ends up as opcodes fed to the processor at whatever rate the processor can take them.

[Energon]

Originally posted by LloydM:
<STRONG>The reason main() is there is because the loader expects this entry point.</STRONG>

But couldn't you redefine the entry point via the compiler... tell it to look for Main::main() instead of a static main() outside of a class?

[Stuka]

Sure you could, but then what you'd have is a class that never got used for anything but a single method - JUST LIKE a main() function in C++ - in other words, you decorated it, but you've really done nothing different. Oh, and the function would still have to be static, or you'd have to create a Main object somewhere - in which case you have the same situation as Java - a main() method wrapped in a class look, but not really being part of that class...

[sans-hubris]

Originally posted by Stuka:
<STRONG>OK, simple fact: in today's current processors (Pentium/Athlon types at least) ALL of the assembly code is linear. Any nonlinearity in execution of assembly code is introduced inside the processor through logic that I don't currently understand :confused: However, linearity (as such) of code execution does not mean that the code cannot be designed in any procedural, OO, or functional paradigm you desire. Object Oriented Programming is a way to design code - in the end, all the code, be it Java, C/C++, Perl, Python, Ruby, Visual Basic :o, Fortran, ADA, COBOL, or anything else, ends up as opcodes fed to the processor at whatever rate the processor can take them.</STRONG>

But this assumes non-parallelization or parallelization without threading (which would be stupid of course). With multiple processors its possible to have multiple operations done at the same time, thus breaking the linearity of the code. In the future with FPGAs and other such more advanced computers, parallelization will be the standard.

[pinoy]

Yes you can as Stuka said, but it doesn't make it anymore object oriented than it is.

It's just wrapping it up in a class namespace.

If the main function is going to be static (like Java), you can get a similar effect with namespace.

e.g.

namespace Main {
int main(void)
{
std::cout &lt;&lt; "blah" &lt;&lt; endl;
return 0;
}
}

// The loader can just run this
Main::main();


But because, when Bjarne Stroustrup developed C++ he wanted it to remain as compatible to C, he chose main() as the entry point of C++ (back then he didn't have namespace to the language yet either).

[Stuka]

Originally posted by ndogg.cpp:<STRONG>
But this assumes non-parallelization or parallelization without threading (which would be stupid of course). With multiple processors its possible to have multiple operations done at the same time, thus breaking the linearity of the code. In the future with FPGAs and other such more advanced computers, parallelization will be the standard.</STRONG>

I gotta say that this is soooo wrong: any code I write, even multi-threaded code, is essentially linear. Now, granted, a spawned thread/process may involve a second linear group of code, which can run on a second processor, but
each thread/process is still linear in nature. How the OS divides these lines of execution (either between processors, or time slices on a single processor) is irrelevant to the linear nature of the code execution.

[sans-hubris]

Originally posted by Stuka:
<STRONG>I gotta say that this is soooo wrong: any code I write, even multi-threaded code, is essentially linear. Now, granted, a spawned thread/process may involve a second linear group of code, which can run on a second processor, but
each thread/process is still linear in nature. How the OS divides these lines of execution (either between processors, or time slices on a single processor) is irrelevant to the linear nature of the code execution.</STRONG>

I guess you're right. Thre really hasn't even been a language written for non-linear programs (mostly because we haven't had the hardware to do non-linear stuff). Having written it one way for so long, I don't think a lot of people will begin to even fathom how to do it. I have some ideas (just from the way I think of things in math), but those might be considered linear too. Strange, from what I've been told, quantum computers will require programming non-linearly because of the fact that you can have superpositions.