IMHO the biggest lack in HLASM in this sort of regard is lack of variable scope. The support for named DSECTs got us halfway there, but symbols still must be unique. If I want to define a struct for C I can blithely name my variables input and output and count and size and so forth. In an HLASM DSECT I have to "fake" scope by naming my symbols CM_input, CM_output, CM_count, CM_size and so forth -- and still hope for the best -- there is still no guarantee of no name collisions.
The assertion that you can do OOP in HLASM just reflects the poster's lack of knowledge of OOP. To your list, add inheritance, overloading, virtual functions, ... I guess you can kind of do inheritance in HLASM. You could define your own DCBD extensions and piggyback them on the end of the IHADCB DSECT -- whatever additional fields you wanted to associate with a DCB such a buffer pointers, counts, NOTE words, etc. In a sense you have defined a child class of IHADCB. You could then GETMAIN storage for this combined DSECT, kind of like instantiating a child class. (Yes, many differences. The weakness of my example kind of proves the larger point: HLASM is not an OOP language.) Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Martin Ward Sent: Monday, February 5, 2018 9:32 AM To: [email protected] Subject: Re: Fair comparison C vs HLASM On 05/02/18 15:03, Jon Perryman wrote: > C has functions to reduce complication. C++ and other OOP languages > have objects. Assembler can easily do this thru macro's and it has > other tools to greatly reduce complexity. How do you define a function using assembler macros? How do you define objects? In particular, how do you stop the programmer from taking the address of an object and examining/modifying the object's internals without using the defined interface?
