Yes I went crazy today starting some threads. I want to get some discussions going on certain subjects and I want people's opinions. Some say OOP is slow, this maybe so, but easier coding can be a result. Also if you know exactly how the OOP is implemented you may be able to optimize it a little. One important thing to note is that it is doable in assembly. Just make a structure that holds -methods a pointer to each method that the object should call -public data public data elements -a pointer to private data required but, if the object is complied in a separate module, what the data actually is will be hidden -inform pointers to methods that inform the object of events Ex)
Please respond. Comments, Suggestions, etc.
Invoke Text1.methods.GetText,ADDR buffer,buflen Invoke Text1.inform.KeyPress,Asciicode TextBox__methods struc GetText DWORD Offset TextBox__methods__GetText other DWORD Offset TextBox__mehtods__other TextBox__methods ENDS ... (fill in any missing info with your brain) TextBox struc methods TextBox__methods <> public TextBox__public <> private DWORD ? inform TextBox__inform <> TextBox ENDS Text1 TextBox <>
Bob, I have mixed feelings about the idea of implementing a particular approach to OOP in MASM. Ernie Murphy's work shows it can be done but I am of the view that trying to standardise ASM into one format is a mistake. It appears that the form you are using may appeal to some people with a C++ background but it does not make them any wiser in terms of what needs to be done to actually write assembler. I use a different approach to "object" style programming, in GUI code I use the window handle as the access into the interface object as it is relatively simple to write all of the required code from the WndProc style function that does the message processing for each window. The instance handle must be made global unless you want every call or object to duplicate the GetModuleHandle() call. To make access to each window "object" I use global handles so that each object can be acessed from others where needed. I don't see the point of depending on the operating system to store global information such as control IDs when you can do it yourself with less overhead. At the non-interface level I use library modules as encapsulated objects and build more complex objects from them as my code requires. This general method is modular programming based on the hardware and it is very hard to beat in terms of speed and size. I am very much a fan of the enormous range possible in assembler and it is this flexibility that I am defending against the idea that one "method" should be adopted at the expense of other approaches to writing code. The particular vision of OOP has been around for a while yet you have people writing assembler that does not restrict them to someone elses "method". I guess it has some to do with the lack of restriction. Regards, firstname.lastname@example.org
Did someone just mention my name in vain? ;-) Once again must I mention ther is nothing inherantly slow about OOP? Line for line, an OOP method call has the same instruction count as any dll call. Go count em if you disagree. Just make sure you count them ALL, as ML.exe and the linker may be inserting a few instructions you might not be unaware of. OOP is not slow. MFC *is* slow, which one can expect when literally everything from the most complex application down to the simplest dword pointer are all objects. After a certain point, the overhead just gets overwhelming. Yes, I published a lot of code that together one may find useful in the creation of COM objects in asm. To that end I have tried to remain faithful to the complete COM 'contract' as I understand it. These objects have proved to be useful in communication with other applications such as data base drivers, scripting engines, right thru to Visual Basic itself. Sine the O in COM does mean object, these are also useful when one wants to put programmable objects to work, even if they are not communicating across process or module boundaries. That doesn't mean I think they are the final word in objects. I too get a sense of raw programmers pleasure when I send a WM_USER message to some window of my own design and watch it perform some function I devised. I'll go hutch one step further (although I'm sure he does this, just omitted for brevity's sake) that I also store instance data in window handle objects, using the GWL_USERDATA dword as a pointer to such instance data, giving each copy of the class it's own distinct traits. (I'll also sneak in the occasional pure procedure that operates on just one window class if I want pure speed over the elegance of a SendMessage.) If you did inside all my source files (you don't think I publish everything I write, do you?) you will certainly find both of these methods, and several others too. If all roads lead to Rome, you have the choice of taking the scenic route over the most direct way. You can even detour to New York for some real pizza. Picking ONE method of implimenting OOP for asm is senseless. Make your code bucket full with the widest palette you can find.
I thank you guys for responding. Obviously I agree. And I bring this into comparison with HLL's. The reason that HLL's are slow is that they have a narrowed view of what a computer can do. They implement things one way and stick to that method. Yes it may not bring the speediest code to code in that manner. Especially with windows controls. However, it may be useful when you are creating a class for data that is not simple and it would be a pain to code any other way. Another thought I have had was making a psuedo-class that is actually just functions that make it look like OOP.