As I see it, you're all using this syllogism: Some programs are overly big and slow These programs were written with OOP Therefor, OOP is big and slow. Nope, A does not imply B. MSVC produces big slow code not because it uses OOP, but because of the way these objects were written. MS attempts to be all things to all people, but we all know you can't please everyone at the same time. And they mostly displease those of us who can't see why a simple "HELLO WORLD" takes 1.4 Megs. When you get down to the bare bones of it, an OOP object method invoke adds just THREE lines of asm code. Compare: Standard dll method invoke:

push paramA
push ParamB
call DllMethod
OOP object method invoke:

push paramA
push ParamB
push this
mov reg, 
mov reg, 
call 
In fact, since this (the object reference pointer) passes such a wealth of information inside it, there is no way the dll method could compete in functionality with the object, it would, MUST include a pointer to some similar structure to do equivalent work. So OOP adds just two fast single-cycle instructions to the code. (Actually, it's equal if you figure in how the linker actually establishes the calls to the dll) Is that bloat? Is that slow? NO WAY! Now, is it possible to bloat and slow down code? Sure enough is. One way is to use MSVC. This language was designed to inherit implementation in addition to interfaces. And it does this at runtime. This means the vtable must be constructed also at runtime (MSVC puts it inside the object itself). Is this a bad thing? Probably not, just 4 dwords per interface. But you can do better if you define a static vtable JUST ONCE for all objects. That's quite possible once you drop to the bare metal of asm and write your own code to do OOP. The bad thing is that in the MS world EVERYTHING becomes an object, and adds extra layers over the most basic API call. And the apps they make are so general in scope they need include so much other stuff you'd not think of offhand. So now to just read a help file, you first need to load a web browser. THAT is where the bloat comes from, not from the OOP base code. I write ASM OOP code to the COM model. If you wish to say "that's not true OOP" I will not argue with you, as it makes as much sense as arguing religions or how many assassins shot at Kennedy. Interface inheritance and polymorphism are done in simple macros. vtables are constructed with dword lists of procedures. Containment may be accomplished by either "following the rules," or creating a seperate .asm module for each class. The code is fast and tight. I watch my current OOP project create a top MDI window, status bar, some tool windows with their own children, and about 16 objects to support the model abstraction, it reads through these objects to extract names, and fills a TreeView with them. It all happens in a flash (on a P233). No lag, no disk thrash. OOP is ASM is damn fast, it's a viable abstraction here as much as in other coding regiments.
Posted on 2001-03-15 10:32:00 by Ernie
I have to agree with you Ernie Fast OOP is possible...in ASM i mean.. and you show it to us... :) Its true that i usually think to OOP as bloatware because of the way MSVC++ doest things (and other C++)... this is a confusion i will have to get out from my mind...in the future :D OOP is not slow or bloatware by nature...but by the way it is done (behind the scenes) by curent "modern" compilers Actually curent "Visual" compilers are bloatware ...but i think that cab be changed if ASM goes in :)
Posted on 2001-03-15 12:15:00 by BogdanOntanu
Yes, I like it, I characterise the distinction between OOP and OOP(s), apart from implementations, OOP is a concept of working with objects and it has a lot of room to be done well. I also agree with Ernie on the passing of parameter data, old style stack parameters work OK but the fastest I have found with benchmarking is to pass the address of a structure in the EAX register and pull it apart at the receiving end. Regards, hutch@pbq.com.au
Posted on 2001-03-15 13:28:00 by hutch--
I think passing the parameters by using the STACK is a good concept (FORTH is based on it) but yes a little slow :( However for a reentrant function is the ONLY solution...and normaly a "GOOD" OS should have ALL system functions REENTRANT so that multitasking/multiuser/realtime is easy and fun... However i have not seen ...yet... an OS (other then FORTH OSes) that have all functions reentrant...today...allmost no functions are reentrant any more...makes me wonder...where did they all learn to make OS? (basic school :D ? ) do i need to say the word "reentrant" once more :D ? but then again...when speed is the matter...register parameters are the fastest way to go. This message was edited by BogdanOntanu, on 3/15/2001 7:43:55 PM
Posted on 2001-03-15 18:42:00 by BogdanOntanu