Well, a week ago this was the furthest thing from my mind but an odd chain of events led me to redesign our old OOP model into this. This has a handfull of benifits for OOP programming in MASM over the previous version

    [*]Method calls are simpler with "Method hObj, Class.method, arguments" format
    [*]Class definitions are simpler, requiring less manual setup. You can define method arguments in the class definition directly.
    [*]Heap memory use is minimized, getting away from coping the same function pointers into every memory object, wasting space. Virtutual function Tables (VTables) are used instead, and defined only once at compile time. One for each class.
    [*]Inheritance can layer as deep as MASM can recurse.
    [*]Polymorphism is supported. However a single or 'straight' vtable is required instead of the defualt linked list of vtables under normal inheritance. This allows for 'interface' definitions as well.

    There are a few trade-offs though.

      [*]You MUST provide at least one method and one data type in the base class. This is because MASM simply wont accept a structure definition with no entries.
      [*]You must use Set/Release object to access data in a PROC for a method. It expects an argument named "lpTHIS". This is because the data for say "ClassA" is in a structure defined as "ClassA_D". Using Set/Release will automatically ASSUME this appended name to a variable.
      [*]Destructors are recursive and have no parameters beyond the manditory lpTHIS argument. It will call "ClassName_Dest".
      [*]Constructors can have variable argments, and not part of the class structure in memory. However they *do* get called. When an object is created, it will call "ClassName_Init" as a constructor. If you inherit a class in a class definition, you must manually call the inherited class constructor. This is becuase of the ability to have a variable number of arguments to a class construtor. There is no simple means of automating this due the potential array of differences between class constructor arguments.
      [*]Like API's the METHOD macro will alter ECX, and EDX. Treat it as such.

      Well this is all i can think off. I have made a very basic example to show it *does* work. As well i have included the NObject.inc file (Objects v3.1b). I call it this in case some still prefers the previous version (Objects.inc) ~ the "N" is for New ;)

      I tried to document it clearly, and point out issues to think about while programming. If you have questions please post them here and I will make more effort to show clearly what your seeking to figure out.

      If you find an error let me know as well. I have tested it alot. But there may be a scenario where it all blows up that I have not thought of. (Im only human ~ and it was made in just uner 5 days <lol> ). However, im pretty confident of my work.

      I hope you find it simpler. I know i do, especially in the header definitions that is required. Enjoy.

      PS: Some has critisized that the previous version has copyright on it. This version does as well, however, i hope i made it clear that you are free to use this to generate programs and sell them. The limitation is that you do not sell this macro source directly, in an uncompiled format (ie. in an IDE or a book that you might write). The exe's that this macro set may produce for you if free for you to profit from (but it cant hurt putting some acknowlegement somewher in the product for the work and research Thomas and I did over the years ;) ).

      PPS: The example uses VKim's debug to output results (yes i was that lazy). Ensure your run the file from a hard drive that has VKim's debug window. (This should be in your \Masm\Bin\ directory, so your "programming" drive should work).

Posted on 2003-07-15 18:41:26 by NaN
Hi NaN, I know I was never a huge OOP supporter but I'm still very impressed with this. Haven't had a chance to test it fully but it feels clean to use if sense to anyone.

I've a prob running the Test_A prog, it just opens 5 debug windows but doesn't print anything. Probably something is amiss with my Masm setup, haven't used it in a while.
Posted on 2003-07-16 12:58:01 by Eóin
same error on my machine (XP). Seems that VKims debug routines have problems with FindWindow API there.

BTW: NaN, your NObject.inc uses LFs to separate lines, not CR LF. That works with most editors, but not with notepad.
Posted on 2003-07-16 15:58:17 by japheth
Thanks for your tip's... I will convert it to use Message boxes, or dos console output... probably the console.

Im surprised the VKim debugger is not working well. I use it 100% of the time on every project. One of the best things that has come along for me.

As well Japheth, I wrote everything in UltraEdit (as with everything I produce). Its the first time i have heard the feedback... but i will see if i can convert it with one of its editor options ;)

Lastly, i have spent most last night developing the first serious class for it. CString. I litterally copied the methods and descriptons from the MFC help file. However, the code is definitely not MFC ;) . It should prove to be very usefull in you projects... Hoepfully i will finish it up tonight.

Posted on 2003-07-16 16:52:26 by NaN
Here is the same source above fixed for console output using Ernie's Debug console macros. You shouldnt have any problems with this.

I also made a very minor revision to the NObjects.Inc file. (( Changed an argument definition in the "BUILD_SINGLE_VTABLE" macro from "Arg:=<NULL>" to "Arg:REQ" )). Nothing critical, which is why i simply changed it to 3.1c.

Japheth, im surprised, i viewed it with notepad and only the Nobject.inc file did this. I think UltraEdit preserves this convention if detected, cause when i hex edited the file with UltraEdit it inserted the "13" (0Dh) even though it wanst there! I have to use a third party hex editor just to proove to myself that UltraEdit is doing something funny here!! Anyways, i did a dos conversion on it and it will open in Notepad now. Thanks for pointing this out!

Posted on 2003-07-16 17:36:59 by NaN
Well Im getting pretty close to finishing up the CString class.. but im still not done. I have a few methods to program still (Compare/Compare no case). As well i will add a couple more not listed (CatString, InString, UpdateFromBstr ).

I plan to use Hutch's compare algo (need to check and see if its part of the masm v8 package).

Anywho, here it is as a serious sample class file. Like i said its not finished, but what is (98% of it) has been fully tested. The notations above the methods have "**" for programmed and a trailing "@" for tested. (my personal system so i dont get lost). All in all any method you see with "** @" at the end of the comment line, is fine to use in your tests and understanding.

Here it is, enjoy! If you have any thoughts, or ideas for others, lemme know.
Posted on 2003-07-16 23:57:00 by NaN
I discovered a bug with the DESTROY macro. The return EAX from destructors were not making it all the way back to your source due to the HeapFree call. This was easily fixed with PUSH/POP.

As such i have made another sub-version of NObjects.inc (v3.1d)

Here it is, enjoy.
Posted on 2003-07-26 13:32:09 by NaN
A few more bug fixes. Nothing major, just making it less restrictive ;)

NObjects v3.1g, Aug 28, 2003
Posted on 2003-08-31 08:26:18 by NaN