I am new to the MASM syntax, and was wondering if there is a reason why PROC declarations are not strong typed to the type of pointer they need? Wouldn't this prevent a lot of errors at compile time? As an example, if a PROC needs a pointer to a string - shouldn't that parameter be defined as a pointer to a string rather than a DWORD (We all know pointer are DWORD on this 32 bit OS :) ) I understand this allows a bit of flexiblity in the pass parameter, but at a great cost. Or, maybe I miss something? Thank you, bitRAKE This message was edited by bitRAKE, on 1/25/2001 12:34:59 AM
Posted on 2001-01-25 00:34:00 by bitRAKE
There is no reason why you cannot use strong type your procedures in MASM. However, the question is do you really want to? Windows defines near a hundred different types that all come down to one thing: A DWORD. Learning that a FOO is of type BAH is declared a BEEP which is finally a LONG doesn't teach you much, and may contribute as many bugs as it prevents. Sure, strong typing does keep you from assigning an hBrush where a hDC is expected, but so should a little common sense. hutch chose to just use just the data sizes in the .inc files of masm32, and I agree with this choice.
Posted on 2001-01-25 00:48:00 by Ernie
bitRAKE, MASM can do strong typing with operators like TYPEDEF but you buy into all of the problems that beset C compilers across different operating systems, with systems that are 8 bit, 16 bit, 32 bit and 64 bit, INTEGER is a different size on each one and this has been one of the major sources of assembly errors in the past. MASM deals with normal data sizes in its own native notation so you have BYTE, WORD, DWORD, QWORD, REAL8, REAL10 and the terms are not ambiguous, you actually know what the data size is. Assembler properly works in addresses rather than pointers and while you can construct a pointer system, it is not intrinsic to MASM. The reason for staying with native assembler data types was to avoid the extra complexity that comes from imposing another language's structure onto assembler, assembler at its most fundamental is simple in structure and this dramatically reduces the error problems if you try and keep it that way. Glad you have come across to MASM, hope you do well with it. Regards, hutch@pbq.com.au
Posted on 2001-01-25 04:26:00 by hutch--
I agree ASM has its own types: BYETE, WORD, DWORD, QWORD just as C++ has its own....(only C finally comes down to us :) ) So its better to know the truth...rather then a nice lie :) I was confused in the past by the LPDirectDrawObject stuff ... until i finally understood its just a DWORD pointer..."then light has come to me :) " Finally i just understand Win32 better After all ASM is not High Level Language! But if you like you can allways define a TYPEDEF in your code :) Bogdan
Posted on 2001-01-25 09:31:00 by BogdanOntanu
BogdanOntanu, True, the Direct Draw include files were defined with somewhat stronger type checking then is standard to hutch's MASM32.
Posted on 2001-01-25 12:00:00 by Ernie
I thought that that might be the reasoning, but I was thinking about making an auto-completing text editor for MASM. If the varibles were typified the selection would be few for the user. I'm just a lazy typer (pun intended :) ) Do you think that it would be a sacrafice that programmer would be willing to make?
Posted on 2001-01-25 21:37:00 by bitRAKE
just to point out, hutch, you forgot REAL4 data type. masm surports the following data types: BYTE WORD DWORD FWORD QWORD TBYTE REAL4 REAL8 REAL10 the FWORD and TBYTE types are generaly not used anymore Also the difference between say, DWORD, and REAL4, which are both 32bits long, is the way masm declares the varibles in memory. This is because, the REAL4, REAL8, REAL10, defintions tells masm we are using floating point numbers, because in memory, the value difference between, the floating point number 10, and the binary number 10, is different.
Posted on 2001-01-26 23:42:00 by X