:tongue: I solved the problem by adding a line "OPTION dotname" to enable the use of a period as a leading character in variable, label, macro, struct, union, and member names. It seems that MASM v6.x does not enable the option although MASM v5.x does.

I suggest to add the line in "Class.inc" in the next version of the Maelstrom's OOP framework.

Regards,
yoursguideline
Posted on 2003-01-05 12:36:01 by yoursguideline
Hi yoursguideline

I thought I did put that in the include file but your right, it's missing - sorry bout that!

Anyone made anything interesting with the framework?

Hope everyone had a safe and enjoyable holiday.

Maelstrom
Posted on 2003-01-05 23:52:47 by Maelstrom
Start a new thread with what you have available.. im personally lost as to where you progress, and your .exe's are at ;)
Posted on 2003-01-06 00:21:04 by NaN
My code is as follows:


.586
.model flat, stdcall
option casemap: none
include class.inc

.CLASS ctest
.STATIC Constructor
.ENDC

.code
start:
.CREATE _ctest, ctest
end start


It can be assembled but there is a link error telling it cannot find some symbols. :confused:

Test.obj : error LNK2001: unresolved external symbol _ctest_Constructor1@4
Test.obj : error LNK2001: unresolved external symbol _ctest_Destructor1V@4
Test.exe : fatal error LNK1120: 2 unresolved externals

Could anyone help me to figure out what problem is? Thanks
Posted on 2003-01-06 13:48:46 by yoursguideline
The .PROTO macro is "too general". It sets all parameters as a dword type.
For example, when i declare
.STATIC abc, 1
I want the parameter to be byte type but the generated prototype is
abc PROTO :DWORD

If i define a method in this way
.METHOD abc, v:byte
a error will occur - conflicting parameter definition : v

:(
Posted on 2003-01-07 02:29:47 by yoursguideline
A minior bug in "common.inc"


.MOV MACRO dest:REQ, src:REQ

IF (( OPATTR( a )) AND 00010000y ) OR (( OPATTR( b )) AND 00010000y )
mov dest, src
ELSE
push src
pop dest
ENDIF

ENDM


Is the a equal to dest? or is the b equal to src?
Posted on 2003-01-07 03:23:52 by yoursguideline
yoursguideline

Oops, missed those when I made the .MOV macro args more descriptive ( a = src, b = dest )

I agree with you with regards to the .PROTO macro. I'm currently working on a preprocessor to replace the macro framework which allows you to define each argument seperately. The preprocessor doesn't have the same interface as the macro framework but is turning out so much nicer, it might be wise to hold off using the macro framework until the preprocessor comes out, should be soon hopefully.

If the constructor and destructor methods don't exist in the code then the linker can't find them. If you have supplied them it's a bug, which I think is the case since the constructor method should be ctest_Constructor1 not _ctest_Constructor1. Looks like I'm using the data name ( _ctest ) instead of the class name ( ctest ) somewhere.

NaN

I'll start a new thread when the preprocessor is stable and bitRake and I have given it a good thrashing. I think you'll like it!


Maelstrom
Posted on 2003-01-07 20:43:46 by Maelstrom
Great! I look forward to it...

:nAn:
Posted on 2003-01-08 00:01:10 by NaN
Sorry, it seems that Maelstrom's OOP framework misses the .DESTROY and .DELETE macro.

Refer to my previous post about the unresolved externals on Constructor and Destructor, I think i can comment on what happen now after some deep investigation.

My code is as follows:


.586
.model flat, stdcall
option casemap: none
include class.inc

.CLASS ctest
.STATIC Constructor
.ENDC

.code
start:
.CREATE _ctest, ctest
end start


It can be assembled but there is a link error telling it cannot find some symbols. :confused:

Test.obj : error LNK2001: unresolved external symbol _ctest_Constructor1@4
Test.obj : error LNK2001: unresolved external symbol _ctest_Destructor1V@4
Test.exe : fatal error LNK1120: 2 unresolved externals

Could anyone help me to figure out what problem is? Thanks

When declaring a static constructor, the .STATIC macro will create a prototype. If there is no defined procedure, the linker raises a error on it.
About the destructor error, it seems that it is abnormal as we don't declare any destructor method. However it is automatically define in .ENDC macro. The destructor is defined to be virtual internally. It does not help when changing it from virtual type to abstract type, since all classes without a base class will inherit a CINTERFACE class. The CINTERFACE class contains an abstract destructor method.
One question is: why does the CINTERFACE declare an abstract destructor method ONLY but not the constructor. The second question is: why does the CINTERFACE declare an abstract destructor method?

Any comment? :tongue:
Posted on 2003-01-09 05:17:17 by yoursguideline
yoursquideline

I haven't looked at the macro code for ages so forgive me if I put my foot in my mouth ;)

CONSTRUCTOR

If your class doesn't need to do any initialization then you probably don't need a constructor. Constructors don't need to be defined, they are optional.

DESTRUCTOR

I defined the destructor automatically in the .ENDC macro becasuse I'm too lazy to type it :tongue: and it must exists in every object. Defining the method this way wasn't a good idea since it hides too much information and can be confusing. The CINTERFACE class is used as a template for all classes so that's why the destructor is defined as an abstract method, it's the responsibility of each class to define its own destructor method.

Abstract methods must be overloaded by another class because they define a method but don't supply the code for it. Think of abstract methods as placeholders.

.DESTROY & .DELETE

These macros are no longer required. The CINTERFACE class contains a Release method which will destroy the object.



; create class object
.NEW blah, CBLAH

; destroy object
.blah Release


Maelstrom
Posted on 2003-01-09 18:39:16 by Maelstrom
I had modifed the OOP framework a little bit. (Override the .STATIC and .ENDC macro and add .SETPROC macro)
Not only we can declare .STATIC abc, 2
where abc is the method name and the 2 is the argument length, also we can declare in the other two forms:

1) .STATIC abc, x:byte, y:dword, z
2) .STATIC abc, x:dword, @proc

The first method will generate a prototype ctest_abc4 PROTO :dword, :byte, :dword, :dword
This just similar to the original .STATIC but the only difference is the type can be customized not just only dword

The second method not only generate a prototype and it will automatically generate a procedure containing the code between @proc and ENDM. For example,

.STATIC abc, x:dword, @proc
    mov eax, 02h
ENDM

will generate

ctest_abc2 PROTO :dword, :dword
_text segment
ctest_abc2 PROC USES ebx ecx edx edi esi _this, x:dword
    .ENTER
    mov eax, 02h
    .RET
ENDP
_text ends

Here i attach the modified part. If anyone interest, show here. :alright:
Posted on 2003-01-12 11:13:29 by yoursguideline
Nice work yoursguideline :alright:

Maelstrom
Posted on 2003-01-14 03:59:22 by Maelstrom
Hey guys does anybody have the link to download this oop framework?

cant seem to find anything but fixes
Posted on 2003-01-16 00:49:12 by monkeyO_o
The filename is mcf100_211002.zip. You can find it in this thread.
Posted on 2003-01-16 07:17:09 by yoursguideline
I wonder the framework progress, I am doing the samething as you do, maybe we can help each other
Posted on 2003-04-25 18:18:11 by taowen2002