Something important about these AVL trees which would make
an ASSEMBLER implementation difficult (not impossible, of course)
is the recursive nature of the problem. The searching is done using
a recursive function which calls itself as often as the tree has levels.
With ASSEMBLER, you would either have to change the algorithm
or you would have to do all the bookkeeping of the recursive calls
yourself (which both is about the same effort).
Maybe you already have an existing mechanism for providing
automatic variables in ASSEMBLER ... but you will still have to take
care to stack the return addresses (and maybe base registers)
of the search function ...
BTW: the comparison between HLLs (C in this case, considered a HLL,
maybe disputable) and ASM should focus on such technical differences
instead of religion.
Kind regards
Bernd
Am 07.02.2018 um 07:21 schrieb Bernd Oppolzer:
I have to admit that I have not much experience with OOP,
I only wrote some C++ programs to do an introductory class
for C programmers on C++ and OOP concepts.
For me, a good OOP example would be, for example, templates.
I coded something in C which I consider OO design, that's a
AVL tree routine, which stores arbitrary data structures addressed
by arbitrary key structures in an automatically balanced AVL tree
https://en.wikipedia.org/wiki/AVL_tree
Because C has no OO support, I had to write it as an include file,
where the types of key and nodes and the compare functions etc.
are inserted by macro variables. This is what C++ tried to solve
historically:
avoid the use of the preprocessor for such things and make for example
types as parameters of templates a feature of the language.
Regarding ASSEMBLER: with ASSEMBLER, you could do this by passing
entry points (of compare routines etc.) as part of the call of (for
example)
AVL tree insert functions, and sizes of nodes (which differ) etc. etc.
That is: I'm sure you could find a solution similar to my C solution
using
HLASM and its macro language. Will it be readable? May be ...
But IMO that's not really OOP, because true OOP has parametrized types
(types within types) and templates as part of the language ...
My 2 cents ...
BTW: I don't really like C++ because of the hidden overhead and the
lack of control ... I like my C solution very much :-) ...
it works on the mainframe (and on every other platform) without
any problem and yields amazing results.
Kind regards
Bernd
Am 07.02.2018 um 06:57 schrieb Paul Raulerson:
Hi Glen - like I said, I am willing to be convinced otherwise, but I
have never seen an OOP program written in Fortran 66. Object Fortran
- maybe. ;)
Care to share an example of what you are talking about? It is
possible we are not talking about the same things. In my experience,
OOP requires specific facilities in a language and run time that just
are not there in straight procedural languages.
-Paul
