Hi all!

First of all I must admit, that I'm a little bit confused. I haven't had visited this forum since my motherboard broke down. It took some time to gather and rebuild some of my resources and tools, but it seems, that everything comes back to the normality. Why confused? Well... I started my work on my own implementation of OOP macros a couple of months ago, rewriting the whole set a couple of times. And I visited back the community a few days ago. And what do I see here? A special section related to the OOP. What's more - I see more and more different OOP macros growing like mushrooms in the rain. So it is not the lonely crusade of NaN no more...

I've been following the paths designed in C++ (and - partialy - in Delphi), so - this could be the main reason of any similarity to other solutions (regarding the keywords, not the code itself). I hope, that I have managed to provide some additional functionality to the whole asm OOP. Who knows? Anyway - the best and basic source of knowledge was Randall's AoA (thanks to him) and some advices given by my old friends in C++...

Features (mostly these, that I consider as more or less innovative):
1) fields of the class are divided to "dynamic" (unique - is it really the best name match?) and static (shared);
2) there are four supported method types: "ordinary", static, virtual and abstract;
3) since abstract methods are supported, the abstract classes are supported too;
4) abstract method calls are not allowed, however - I've designed a special type of method call, provided just for abstract methods. A pure abstract class (consisting of abstract methods only) is a (more or less) flexible way of handling COM interfaces;
5) since method prototypes are always PROTOs, the true body of each method can be defined in any part of code: in a different module, in a separate LIB or even in a DLL (this one has not been tested yet);
6) (theoreticaly) unlimited inheritance level
7) pure static classes (consisting of static members only) could work as templates for projects (design a static class, build "common" static methods and declare other static methods to be built by the user)
8) auto constructor / destructor calls - be warned and expect an extra INVOKE after creation or destruction of an object;
9) no "default" constructors / destructors (this one match the Delphi type, not the C++ one)
10) polymorphism support
11) a simple system of error messages, so the whole set has an average error protection

Things to do, missing features and expected troubles:
1) auto chain-call for constructors and destructors of derived classes - since direct constructor / destructor call will not be allowed (to be implemented), this feature is strongly required in case of derived classes (I have already built the scheme in my head, but it hasn't been done yet);
2) some minor features like ISCLASS function;
3) due to the huge amount of information stored by the compiler, a really extensive use of classes may cause an overflow of global symbol table (proabably? not tested...)
4) due to the huge number of local parameters, an extensive use of classes may cause an overflow of local symbol table (local symbol redefinition error) - this one is more proabable and was tested against the size of LST, however - I do not expect to meet such an error in most of cases. Anyway - I'm going to optimize the usage of local parameters, so the problem should be reduced (but not eliminated)
5) I still have to write a simple reference :) On the other hand - we don't have such a good forum in Poland, so I will surely write a small set of tutors in Polish. Dunno whether to do it in English also - there's a lot of better sources here and in AoA...
6) The whole set shall be only a part (but the most important part) of the full extension called HLX (Higher Level Xtension), which includes other macros, divided into "language" macros ($INVOKE, SWITCH/CASE, RETURN, a.s.o.) and asm macros (like MOVM - provided for moving DWORD operands from MEM to MEM directly)
7) I have noticed a strange behavior of the whole set while using STRPTR macro (equal to the known CTEXT), so I was forced to add the location pointer workaround. The methods were simply loosing the last few bytes of code without it - dunno why... I can share an example of this bug, if necessary.

Well... The code is a little bit messy in the last part, but it is only a beta version and it hasn't been heavily tested for bugs. I have left the possibility to make a direct call to the constructor and destructor of an object - just because I've not implemented the auto chain-calling for a set of derived classes. If necessary, perform a direct constructor / destructor call from the constructor / destructor of a derived class to the one of parent class. However - it will be done automaticaly in a nearly future.

A small sample app (with executable and a commented fragment of disasm) and a quick macro reference included...

Hope you'll like it. Regards, Mikael
Posted on 2003-09-08 18:13:40 by MikaelC