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)
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,
hutch@pbq.com.au
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.