Re: ///Wannabee Rants


//\\o//\\annabee <Free" wrote:

This can also be done with RosAsm macro system, checking for sizes of
labels. and registers as well, I belive.

Really? Why don't you show us, then?

Not that I could ever imagine any
need for it.

Sevag just gave you an example of why it's useful. Read and learn.



Still it will not protect from a perverted register,

No, type checking won't catch every possible semantic error out there.
That's why it's called "type checking" rather than "all possible error
checking."


so what is its
advantage that warrant all this code mess ?

Because it *can* catch many errors. And the result is *far* more
readable to someone who is not intimately familiar with the code, but
needs to modify it for their own purposes.

Your code is very much more
verbose, killing readablity.

Wrong, dude. Conciseness, especially at the level that RosAsm
programmers tend to operate, is what kills readability.


This is imho like having a cloud around you
head when coding.

You seem to forget that code is written *once* but read *many* times.
Yep, having to explicitly specify things makes the code a bit more
difficult to *write*. But reading, understanding, and maintaining the
code, especially by someone other than the original author, is much
easier when the code doesn't look like an explosion in an alphabet soup
factory (the best way to describe most RosAsm programs I've seen).


Very brutal and very plain facts.

I've seen your code. Granted, Rene's is worse, and maybe a/b's as well.
But you'll have a hard time convincing people around here that your
code is readable.


Should imo been
forbidden in programming.

Look in the mirror.

This is nothing but reinventing spagetticode.

???
You don't even know what the term (spaghetti code) means, do you?

Look at my plain asm code. It is tons better from all points of view.

People around here have. You've posted lots of code over the years.
Mostly it gets ignored. And when it doesn't, the comments haven't been
pretty good.


Proc SaveObject:
Argument @BaseObject
mov edi D@BaseObject
BaseObject.vCall vSaveObject
EndP

First of all, on a trivial code sequence like this, it is impossible to
get a feeling for what your writing style is like. Nonetheless, the
code above is still unreadable. Though that is more due to RosAsm
bizarre syntax than your coding style.



To do what. You havent told us what it can do. In addition to
distinguishing types. Distinguishing types is easily done with a
calltable, the way I described in my post to betov. Thats what objects are
for.

Yeah, like Rene you would do things at run-time that really ought to be
done at compile-time. And you have the nerve in other posts to talk
about how assembly language has all the advantages over assembly while
writing such poor code.


For the above, you would first need a "Proc" macro that can determine
what types of data to accept.

This is by default done. It takes an object. Only if if you pass it a
perverted pointer will it fail. And typechecking cant guard againts this.
You said so yourself.

You really need to learn what the term "type checking" means. You
embarass yourself with your ignorant comments.


In Rosasm case, It's practically already
in the syntax, all you would need is for the macro system to recognize
"Argument" items as types that you have declared elsewhere:
It would be roughly:

[@BaseObject 4] ; define "BaseObject" as type with 4 bytes

[myClassPtr @BaseObject] ; reserve 4 bytes for myClassPtr as
"BaseObject"

This isnt RosAsm valid syntax. Actually crash RosAsm. And such a simple
syntax...

So why offer it as an example? Why not give us real stuff that actually
works rather than fantasy wish lists?


Proc SaveObject:
Argument @BaseObject ; declare parameter 1 as type "BaseObject"
mov edi D@BaseObject
BaseObject.vCall vSaveObject
EndP

invoke SaveObject, myClassPtr

Now if you passed the wrong pointer type, the macros processor would
know and give an error.

And how would it do that?
Why don't you explain how this works rather than just making stuff up
that sounds plausible? Give us a real example; one that won't "crash"
RosAsm.


So this is a compiletime feature trying to prevent a sleepy programmer
from making a bug?

I can't really tell. I don't see how this would do what you're
claiming. Why not explain it to us?



But this is a simple use of type checking. A
more significant use, as demonstrated earlier is when a macro can do
various things according to the type of data passed to it.

What we have objects for.

No, that's not the purpose of objects. Once again, you're trying to use
run-time structures to take care of things that should be handled
statically, at compile time.


For
example, my "buffer" class can accept input data from many different
pointers: signed/unsigned 8/16/32/64/128 (converted to ascii), char,
all standard types (as data bytes), strings, streams of data with
address offsets, another buffer class, etc.

Some of this is also possible with RosAsm macros. but what is a typical
use?

Take a look at the HLA stdout.put macro sometime.



I cant see why. Is this extendable to userdefined types?

Yes.

Scanning all those types could take lots of time in a large project.

At compile time, when it should be done, not at run time. Some day, I
hope you figure out what the difference is.

Thats why OOA was invented, to do this directly via calltable.

No, that's not why OOA was invented. If you think so, it demonstrates
that you don't have a clue about object-oriented programming. Not
surprising, as you don't even know what type checking is about.

fair enough. This has been debated to death. Thats exactly why I try
another angle. I am trying to understand the _advantage_ of type checking,

The first, you should study programming language design and *learn*
what type checking is all about. One would have thought that with the
10 years of Delphi experience you've claimed to have, you'd know all
about type checking (as well as object-oriented programming). That
doesn't appear to be the case.

in order to understand why it is important enough for you to require it by
an assembler.

When you learn about the benefits of type checking, you'll probably
want it in assembly language as well :-)



What I have understood now, by master PDFs and your posts, is that it is
for catching mistyping bugs.

That is one thing it's good for. It's also good, as Sevag as pointed
out, as a tool for directing code generation during macro expansion to
generalize those macros.

And maybe also a primitive form of OOA that
does not scale.

It has nothing to do with OOA.
And I suspect you don't understand what the term "to scale" means,
either.

Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
    ... > This is a real problem with SoftWare (not only RosAsm), ... > some quantity of Functionalities, ... the harder it is to "keep up" with the documentation... ... >> powerful macro system (you know, perhaps you don't feel it's better ...
    (alt.lang.asm)
  • Re: A (mild-mannered) defense of RosAsm
    ... there actually *are* some features in RosAsm ... > All these debates over RosAsm's macro language remind me of Jerry ... There are actually *weaker* assemblers out there than I fully support. ...
    (alt.lang.asm)
  • Re: Why I stop attacking HLA
    ... and I've been doing assembly language programming since about 1976. ... RosAsm just isn't be accepted by too many people. ... > learn specific programming techniques that just happen to use assembly ...
    (alt.lang.asm)
  • Re: In search of the perfect Disassembler
    ... Does RosAsm not get it exactly right? ... Having written a couple of books on MASM (The ... > make use of Short and Long Jumps, ... there are far more examples of *very* sophisticated macro ...
    (alt.lang.asm)
  • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
    ... This is a real problem with SoftWare (not only RosAsm), ... > macro system"...indeed, one of the more attractive things about HLA - ... The "Modular" Concept is the first step to hell. ... a way for Linux. ...
    (alt.lang.asm)