Re: GAS struc

the-o/-/annabee wrote:
> the-o/-/annabee wrote:
>
> "
> Sure. And you've rewritten the Delphi VCL, too (or so you've claimed).
> "
>
> PARTS of it. Yes. parts of it.

No. You've subclassed a few classes in the VCL. Why don't you post your
claims and your source code to a Delphi newsgroup and see how far it
flies. Have you forgotten the drubbing you got around here when you
posted a link to your code and those who knew just a little bit about
Delphi had a field day with your claims? My, what a short memory you
have.

>
> "
> As you readily tell everyone around here, you're just a beginner. What
> makes you think you really know what structures are all about?
> "
>
> Because I am right now writing a component library in assembly ?

And how does that qualify you to know what structures are all about?
Clearly, looking at the examples you've posted here, you don't really
have much of a clue. And when your component library is finished, you
still won't have a clue because you're doing it all wrong. I'm sure
all the RosAsm community will think it's great, but if your ideas are
so good, try translating them to MASM and convincing the MASM
programming community (or TASM) to use them. They'll laugh you back
into oblivion. Using equates is *not* the way to do structs.



> When done, it will be not only as capable as the HLLs once,

No, it will not. Maintaining and reading the code is going to be a
nightmare. The problem with your equates scheme is that it *looks* like
it's working great as long as all the code is perfect and is static
(non-changing). The moment, however, that someone tries to make
substantial changes to your code, they're going to discover that it's
just a 'house of cards' and it falls apart when they attempt to do
things with it that you didn't anticipate, like changes that
necessitate changes to the fields in the structures.


> but will BLAST them away with superiour performance.

It will be a BLAST already. I expect it to BOMB, for sure.
The coding style you're using is not robust at all. Again, with a lot
of work you can make the program *appear* as though you've used structs
properly, but the moment things have to change, it will come falling
down on you. Don't forget, I played this same game with my 6502
assembler LISA. I'm quite aware of the limitations of this scheme. I,
too, was quite proud of what I did back then. But after writing code in
that style for a while, I finally figured out that equates are no
subsituted for true structs. Someday, perhaps when you grow out of
your beginner phase, you will come to understand this point.

> My hand tailored Object memory manager is MANY times faster then
> the Delphi one.
>
> "
> Granted, after two years, it's fair for us to think you ought to have
> moved
> beyond the beginner stage, but if you're going to keep claiming you're
> a beginner, who are we to doubt such a claim.
> "
> I am a beginner in asm. Two years is nothing in programming, imo.

No question that some people are slow learners and two years is not
enough time for them to become expert programmers. But I *would* remind
you that you've claimed to be a 10-year veteran of Delphi (which was
*barely* possible back when you made the claim, you must have started
with Delphi 1.0). That being the case, I would have expected you to be
a little bit farther along with your assembly programming by now. The
truth is, it should only take about six months to become a half-way
decent assembly programmer if someone has had ten years programming
experience in Delphi. Or maybe you weren't quite telling the truth
about your programming experience? Even so, most programmers have a
pretty good idea about how useful structs are well before they've
reached the two year mark.


> But
> fortunatly for me, asm is so easy,

If it's so easy, why are you still a beginner after doing it for two
years?

> that even a beginner can make use of
> it. And thats exactly why its important to teach the many who have
> forgotten and or swallowed the HLL Gospel.

If it would take them two years to get to your level, I can see why
they'd forget all about assembly language and do all their work in a
HLL.

> Asm is EaSIER then HLLs. MANY MANY MANY times easier.

Yet with a HLL, people are doing things a bit more sophisticated after
two years than you're doing in the examples you post here. For example,
they generally understand how to properly use structs/records in their
programs. They don't do stupid, unmaintainable, things like creating
constants to provide offsets into a struct/record and then manually
applying those offsets to a base address. It's one thing to claim
people should *understand* how structs work; it's another thing
entirely to argue that people should implement structs manually, as you
are doing.
>
>
> > Using equates, unifies all other uses of structures.

Sure. And using Hex opcode encoding unifies everything. So why don't we
all work in HEX?
Whatever benefits your concept of "unification" may have, it certainly
doesn't make your code easier to write and maintain when you manually
implement structures the way you're doing it.

>
> "There is no question that you can do *anything* with equates that can
> be done with structs/records/unions/classes/etc."
>
> Correct!

Of course. But that doesn't mean it's the *right* or *easy* way to do
it. Only that it can be done. Like I said, you can work with numeric
representation of all the machine instructions too, but few people are
stupid enough to think that this is the right way to write code. Only
people who don't have access to a decent assembler would think it's
okay to write code that way. Likewise, only people who aren't using a
decent assembler that doesn't support features like structs would ever
claim that equates are a better way to do this. If RosAsm supported
structs, we'd be hearing you preach the virtues of "true structs", no
doubt. We all saw the same thing when (a weak form of) conditional
assembly was added to RosAsm; before Conditional Assembly, the RosAsm
contingent pooh-poohed it, claimed it was worthless. After Conditional
Assembly was (finally) added, they started praising the facility. No
doubt, it would be the same with structs if Rene were capable of adding
true structures to RosAsm.

>
>
> " Heck, you don't even need equates, you can use literal constants for
> all your offsets. The
> result, however, is unreadable and unmaintainable and takes a lot more
> work to get right."
>
> Useless propaganda. I have written 2 megabytes of HIGHLY maintainable,

Yes, I'm sure *you* think your code is maintainable.
How many other people can maintain it? Just your "gang of 2000" I
suppose?

> very well structured asm code,

What makes you think your code is "very well structured"?
Heck the fact that you cram multiple statements per lines (a well-known
old-fashioned BASIC programming technique that is a faux-pax to the
rest of the programming community) speaks *volumes* about how well
structured your code is. The fact that you are using equates to
simulate structs tells us even more.


> in less then 2 years in assembly, and I
> had never written a complete program in assembly prior to this except
> for a disk i/o routine callable from pascal, several years ago.

And those "10 years of Delphi experience" count for nothing?

> Now I
> have written, at least 2 megs of code,

Cut and paste works wonders, doesn't it?


> when putting all the projects
> together. All the projects use the excact same codebase, and if that
> doesnt show its reusable...

Ah, yes. You think "cut and paste" coding is "reusing code" and is an
example of "very well structured code". Yes, you really *are* a
beginner, aren't you?


>
> A few days back I found out I wanted to have the ability to run my
> windowless gui, in multiple windows as well and it took me about 3 days
> to work it in.

Why so long? If you're coding style is as great as you're claiming, it
should have been automatic.

> And this is because the code is extremly well suited for
> maintance and insertions like this.

If it took you three days to coerce the code to behave that way, it's
not "extremly [sic] well suited". It might not be *that* bad, but it's
certainly not extremely well suited by any means. If it were extremely
well suited, you would have instantiated three class objects and you
would have been done with it.

> If you want to take a look, the
> link is here :
> < http://www.szmyggenpv.com/downloads/CurrentProject.Zip";.

No offense, but given the quality of the code you've posted around
here, I'm not willing to subject myself to such torture :-)


>
> In the following days I will extend this to the menues, so that they
> climb over windows. And most of the changes are trivial. AS long as I
> can cut this useless trolling debate with you short.

IOW, it really *wasn't* three days. It's an on-going effort. I remember
you making claims about your productivity like this in the past. You
make some bold claim about how it only took you a week or two to
achieve something and then a month later you're still posting comments
about the changes you've made to the code. Finish the whole
modification. *Then* come back and tell us about how wonderfully
maintainable the code has been. If you take a microscopic view of your
code, it's easy enough to say "look how maintainable this (small)
section of code is." The real problems occur when you have a larger
code base. As the code gets larger, the complexity of the code
increases quadratically. Working on a code base that is twice as large,
for example, often requires four times the effort. Conversely, working
on tiny sections of code is generally pretty easy. I suspect this is
your problem hear, you're working on small fragments of code and
generalizing the effort needed to make a small change against an entire
project. Once you take a look at the whole project, I think you'll find
that it's a *bit* more complex than you're letting on here.

>
> "No doubt, if you used a software development tool that allowed true
> structs in an assembly language program, you'd be preaching their
> virtues."
>
> I give you a maybe on this one. But I am very thankful that RosAsm
> doesnt support the kind of structures you use, because then maybe I
> wouldnt have discovered, the fantastic simplicity and superb
> flexibility of the RosAsm equates.

Of course, if you read some decent programming books, that explain how
structs/records are implemented in memory (e.g., my "Write Great Code"
book, or even chapters 4 & 5 in Volume 3 of the on-line edition of
AoA), then you could know all that stuff and be more effective writing
code, too. NEVER settle for a tool that forces limitations on you and
then pass it off as being okay because "well, it forced me to learn how
to do this stuff manually." Learning how to do the stuff manually *is*
important. It is the primary reason people learn assembly language
programming these days. But the need to know how to manually do
something does *not* imply that you ought to be *doing* it manually in
actual code.



> And this possibility, is exactly why
> its so important to have theese debates, because you are exactly
> makeing theese very misinformed desisions on behalf of your users,

What misinformed decisions are these? I certainly argue that people
should *know* how structures/records are laid out in memory. They
should *know* how to access the fields manually, if needed. If I didn't
believe this, why would I devote a whole chapter in my book to teaching
it? But that doesn't imply that this is the way that I think people
ought to be *writing* code. They should know so they can make an
informed decision about using structs/records (versus other data
structures such as parallel arrays). But hand-code the offsets
themselves? Nonsense. That's like suggesting that people should
hand-code machine opcodes themselves. It's important that they
understand how binary machine opcodes are constructed (and yes, I
devote a couple of chapters in my book to that process, too); but
hand-coding machine instructions is *not* what you teach people to do
if you're teaching them to program in assembly language.


> if
> any (??), and thus leads them away form the path to enlightment in
> computer language.

No. Suggesting that they use arcane, frustrating, and error-prone
techniques, like hand-encoding offsets into structures is a sure way to
chase them back to HLLs where they don't have to do this kind of
nonsense.

>
>
> "But as your tool of choice fails to supply this, you feel some sort of
> ackward need to justify the lack of support. Go ahead. Just don't
> expect anyone to believe you. "
>
> I have no hope, nor need for anyone to belive me.

Which is real good. Because no one *does* believe you. Trust me.
Okay, that's a lie. Sometimes Rene actually believes you. Shows you
what kind of an "expert" he is, doesn't it (I mean, come on, you're
just a beginner, right?)

> Unlike you, and
> sevag, I dont have to be belived, because I have proven everything I
> say here,

Really?
Exactly what have you proven?
Why don't you give us a list? Along with pointers to the proof you've
provided. You've made a lot of noise and a lot of baseless comments,
even sprinkled in a lot of profanity. But about the only thing I've
seen you prove is that you're still as disagreeable as you've always
been.


> and written it in open source software, that anyone can look
> at.

And people have. And people have laughed.
I won't suggest that *everything* you've ever written is bad, but the
code you're posting to this newsgroup isn't what most people would call
"very well structured".

> All the claims I make can be verified.

You mean like "I have rewritten the Delphi VCL"? Remember when you made
that claim? You had to leave this group in shame because people were
tearing you apart.

You claim that I am a liar and a swindler. Prove those claims.

> I do hovever have a strong
> need to guard the truth from swindle and lies.

You mean, like "I have rewritten the Delphi VCL?"

> And even I could give
> Sevag, that he has maybe an honest heart and means well, this is
> certainly not the case with you. You have a ruthless and visious plan
> to destroy assembly,

"All the claims I make can be verified"
Okay, prove that I have a ruthless and 'visious' [sic] plan to destroy
assembly. This is a claim of yours. Verify it.


> and is doing it with the craft and precision of a
> visiuos and illtempered obstipated snake.

Prove it.

> The propaganda you spread are
> intended for the fainthearted beginners, and you do not belive a word
> you are saying yourself,

Prove it.

> you just try your best to lead the little
> lambs off the path to enlightenment

What path of "enlightenment" might this be?
No doubt, I am teaching students to avoid doing stupid things like
using equates to manually set up offsets into structs. But if you think
that this is bad, *prove it*. Show that using equates is better than
using true structures.

> and in to the *** of HLA.

You are claiming that HLA is ***. Prove it. In particular, post the
chemical composition of *** and verify that HLA has the same
composition.


>
> > If you use equates, which have only one simple rule of usage, you can
> > seamlessly build simple types, and build complex autoscalable records
> > from theese types, and create objects and classes from the records ,and
> > simple types, or convert back and forth as you wish.
>
> "And wind up with an unmaintainable, unreadable, mess. "
>
> My code is the most readable source of any I have seen. :)

Every programmer says this about their own code. It's almost a given.
The measure of readability, however, is *not* how readable a programmer
finds his or her own code to be, but how readable an average mix of all
*other* programmers find their code to be. And let me suggest that most
programmers don't think that using equates for offsets into structs
produces more readable code than using actual structures. Most
programmers don't think that cramming as many statements per line of
code as possible produces more readable code either.


> It is also
> the most maintainable.

Compared with what? If you honestly think that using equates to
simulate structs is more maintainable than actually using structs,
well, most programmers disagree with you (in fact, the only ones I find
agreeing with you are other RosAsm programmers; I wonder why?)

> Its by no means any accident that I added almost
> a mega byte of code in two months this summmer, while you wore sitting
> around hiking your asses :))

1) Cut & paste works wonders, doesn't it?
2) You have no idea what I was doing this summer, so what makes you
think you can comment on that?

> Also, this proof Betov correct as well. The things I experience with
> RosAsm, an incredible productivity, combined with excellent overview of
> my sources organization, corresponds exactly to the things he says in
> the BU_ASM.

And you have lots of experiences with other assemblers so that you
*know* you're more productive with RosAsm? Sorry, but if your
statistical sample is one, you can't be very sure of the results.

> Even I have broken a few of his "re-commandments" :)) ! For
> instance, I DO write modular with RosAsm. And I am very glad if it
> turns out I can prove him a bit wrong on this account. I sure as hell
> is unable to prove him wrong on any other.

I find it so amusing when a new feature like conditional assembly gets
added to RosAsm and people start preaching the benefits of the new
features; months before, they would argue vehmently against the need
for the feature. So much for the things Rene says in B_U_ASM. (BTW, the
last time I looked in B_U_ASM, he was still telling us how useless
conditional assembly was; and this was long after the feature had been
added; is your memory that short, too?)


>
> "
> Keep in mind, I've written lots of different assemblers over the years.
>
> "
>
> How the hell do you suppose ANYONE could fail to keep that in mind. You
> been saying it for what seems like AGES!

Sure. I've written assemblers for ages. The fact that the first couple
of assemblers I wrote were written *long* before you were born probably
has something to do with the fact that *you* have never heard of them.

> However, nobody has ever seen
> an assembler you created! Strange huh?

Just because *you* have not heard of them, doesn't mean no one else
has. Just Google for the LISA assembler some time, for example.

>
> "My first assembler used equates, just as you're proposing, because I
> had neither the experience nor the desire to add those facilities (this
>
> was in the late 1970s, btw). "
>
> You are selfdelusional, if you think you could be able to do what I did
> now, back in 1970 :)) :)) Of course, this is news to noone.

1) I did not say 1970. I said 1970s. Let's make that fact real clear
before some other fools around here start claiming I wrote an assembler
for the Apple II eight years before it appeared on the scene.

2) As for being self-delusional; there is *one* important piece of
truth to what you say. Back in 1978/79 (when I wrote LISA and another
6502 assembler) we didn't have "megas" of memory to play with (RAM or
disk). So we tended to write smaller code. The LISA assembler, for
example was about 12-16K when it first arrived. A bit tighter that the
stuff you're doing. And you couldn't achieve that by cutting and
pasting your way to glory.

3) Back in 1978/79 when working on the LISA assembler, I was using
equates to provide offsets into structures. Actual structs in
assemblers weren't exactly common then, and certainly unheard of on
limited memory machines like an Apple II. I suppose you think that you
*invented* the idea of using equates to form offsets into structures?
Sorry dude, that idea's been around since the earliest days of
computers. But if you think you can patent the idea, give it one big
try.


>
> "Later on, when working on a National 32000 assembler I created a
> solution similar to that employed by NASM and
> FASM (meaning I *do* know what those assemblers are capable of doing,
> having done that stuff myself).
> "
>
> Well, maybe I could belive you,

And no reason not to. If my PC532 system were still operational
(running Minix), I'd be more than happy to put the source code up on
the net for you. (info about the PC532 is here
http://www.netbsd.org/Ports/pc532/faq.html, if you'd like some
verification of my story).

> but I allready read some of this post
> below, and there you are simply makeing an ass out of yourself. SO I
> guess, you words up here is not much diffrent.

Well, you can't contradict what's being said, so you go back into
personal attack mode. How typical of a RosAsmite.

>
> "Though it was a *ton* more work, when
> designing HLA I decided to do it right.
> "
>
> I can't figure even one things that is "right" about HLA.

No doubt. You've never bothered to learn HLA. At least *I've* spent
some time with RosAsm, so I have a small inkling of what the product's
all about when I discuss it. However, I've yet to meet a single one of
the RosAsm crowd that has done more than install HLA and run a canned
source file through it. Given that experience, you guys really have no
grounds for commenting on HLA.


> HLA is
> everything upside down.

How is that? Prove it.

> HLA is a nothing but disgrace to assembly.

How is that? Prove it.

> I
> downloaded HIDE today, and compiled a few lines of code. In RosAsm, you
> have to compile 500K or more in order to miss an instant compile, but
> this HIDE thingy, took a 5 seconds PAUSE for compiling maybe 5 lines of
> code.

No question about it, HLA is one of the slower assemblers around.
But your "five lines of code" characterization is flawed. How many of
those "five lines" were "#include" statements and how many lines of
code where in those include files?
I realize that the concept of include files is a bit foreign to RosAsm
users, but your lack of experience here, is again, telling.

> On a AMD 1800, Thats disgraceful.

On my PIV 2.7 GHz system, HLA typically operates at about 5,000-50,000
lines/sec, depending on the density of macro invocation. Certainly not
as fast as some other assemblers, but hardly disgraceful.

> That so patetic, if I wore you
> I had better kill myself.

Well, assembly speed was never a goal for HLA. Providing a rich feature
set was. If I were a RosAsm user, with its pathetically small feature
set, I'm sure I'd kill myself, too.

> This is compromising HIDE author reputation,

Most people I know that are using HIDE don't have many complaints with
the system.

> but indeed, it is entirely your doing.

I don't think Sevag is complaining too much, either.

> His part of the work seems well
> done.

Sevag has done a fine job, yes.
I guess that is one other area where you differ from Rene; Rene
constantly attacks and insults Sevag. At least you have the ability to
see that what he has done is pretty good.

>
> "
> Writing a little parser that converts a list of names into numeric
> offsets is *not* doing it right.
> Then again, that solution is *far* preferable to the one employed by
> the tool that you happen to use (letting the IDE create templates to
> cut and paste into your code).
>
> RosAsm is an development ENVIRONMENT,

Yes, no one is questioning what RosAsm *is*. What we're questioning is
that you call it an *assembler*. The assembler is actually a *tiny*
part of RosAsm (about 10-15% of the code the last time I checked). This
leads poor little lambs, such as yourself, down this path where they
think that an assembler is an IDE, a dialog editor, a debugger, a
disassembler, etc. An assembler is none of these. An assembler is a
compiler for an assembly language. Nothing more. When someone makes
claims about how great an "assembler" is, because of its dialog editor,
that pretty much tells you that they've been mislead about what an
assembler is. You talk about how I'm misleading people by claiming HLA
is an assembler. But HLA is a compiler for an assembly language and
*nothing more*. That makes it an assembler. You may argue about the
*language* itself, but what HLA v1.x (the implementation) is, is beyond
question.


> ten times more significant than
> any other such environment yet to be seen. Yes, much much more
> significant then C++ and such banalities.

Prove it. And how much experience do you have with C++ and such
"banalities" in order to make such a generalized statement?

>
> > Its only one ability of stucktures that cannot be done by default with
> > equates (but could be implemented with a blindfold in any language),
> > and that is "type checking".
>
> "No, there are many other advantages. Instantiation being the primary
> one. "
>
>
> I showed this. The Size equates are directly feedable to the
> memorymanager.

And you think that's all there is to instantiation?
Someday, I hope you get into college and take some programming language
design courses. Then you will realize how foolish your arguments have
been.

>
> "Being able to create recursive data structures"
>
> Recursive? Are you insane? Noone could do that. It would be an error.

Someday, I hope you get into college and take some programming language
design courses. Then you will realize how foolish your arguments have
been.

> What you speak of is a referance to a data of the same type as the
> decleared data, via a simple pointer assignment, and it is trivial
> todo. There is no such thing as a recursive datastructure. Thats a
> freak monster in you brain only.

Someday, I hope you get into college and take some programming language
design courses. Then you will realize how foolish your arguments have
been.
>
>
> "(records within records, "
>
> I allready shown this with the MyWindow structure in the reply to
> sevag.

No, you did not.
You may have *though* you did, but you did not.

>
> "arrays of records, "
>
> I showed you this last time we spoke on the subject, but, here it is
> once more
>
>
> [SizeOF_ArrayOfRects (MaxArray*SizeOfRect)]

C'mon, get real. In MASM, I can write

arrayOfRecords db 256 dup (?)

and claim that I've created an array of 16 16-byte records. That's not
what's happend here, though. I'll I've really done is set aside storage
for 256 bytes. The fact that I can overlay this storage with such an
array of structs does *not* mean that I've created an array of structs.
Again, you simply don't know what you're talking about here.

>
> [ArrayOfRect: B$ ? #SizeOF_ArrayOfRects]
>
> Proc ForEachRectangel:
> Argument @CallThisProc
> mov ecx SizeOF_ArrayOfRects
> add ecx ArrayOfRect
> mov edx ArrayOfRect
> L0:
> Call D@CallThisProc
> add edx SizeOf_Rect
> cmp edx ecx | jb L0<
> EndP


You've created an array of bytes, not an array of structures. You *do*
know what "B$" stands for in RosAsm, do you not? No one is arguing
that you cannot create some equates to specify the size of a structure
and then statically allocate storage for this structure with RosAsm.
Heck you can do that sort of stuff when writing in straight binary
machine code. Nothing special there. The comment I'm making is that
the *moment* you deviate from the simple "equates produced by the
RosAsm IDE" model of structs, you wind up turning everything into byte
arrays. Unreadable. Unmaintainable. It would be fun to see Rene add
real structures to RosAsm and see how quickly you change your tune
about this (but fear not, I'm afraid your "expert" Rene doesn't really
know how to add structs to an assembler, or it would have been done a
long time ago).

>
> "
> records containing arrays, "
>
>
> Record1.RectArray1 0
> record1.RectArray2 Record1.RectArray1 +
> SizeOf_ArrowOfRects
> _____________________________________________________________________________
> SizeOf_Record1 record1.RectArray2 +
> SizeOf_ArrowOfRects]
>
> - Trivial.
>

All I see are some equates. Where are the structures?
I didn't say that RosAsm couldn't create all kinds of equates. I said
you can't do nested structures in RosAsm. The above is not a structure.
It's just a couple of equates.

>
>
> "
> records containing arrays of records"
>
> ok,
>
> [SizeOf_ArrayOfRecord1 (MaxArray*SizeOf_Record1)]
>
>
> Record2.RecordArray1 0
> Record2.RecordArray2 Record2.RecordArray1 +
> SizeOf_ArrayOfRecord1
> _______________________________________________________________________________
> SizeOf_Record2 Record2.RecordArray2 +
> SizeOf_ArrayOfRecord1]
>
> completety trivial.

And still not a structure. No one is questioning that RosAsm can add
two numbers at compile time.


>
>
> To order memory dynamically for the whole shits :
>
> GetMem SizeOf_Record2
>
> ---------
>
> or [TestRecord: ? #SizeOf_Record2]
>
>
> "
>
> , and stuff like that) is a *huge*
> advantage over the simplistic equate scheme.
>
> "
>
> Absolutly not !
>
> This is childplay. I can access any member in those structures easily
> using equates.

Yes, I'm sure you can. :-)

> Not that anyone with a brain would ever need to do something like that
> in a real app!

That speaks volumes about your experience.

>
>
> "
> And being able to specify alignment in a programmatic fashion (e.g.,
> align the fields one way for
> one version of the structure, align them differently for a different
> version of the structure). "
>
>
> This is redicolously easy. Are you so newbie you are unable to do this
> with a set of equates ?

Really? Show me how to set up your structs so that you can easily
follow the Intel ABI for alignment, use packed alignment, or use dword
alignment for all fields. And select any one of these by modifying only
one line of code. Easy in HLA. And not so hard in MASM. And do this on
a struct-by-struct basis. Then tell us again how maintainable your
scheme is.

The problem, you see, is that you create all these fixed constants like
"sizeof_xxxx" and the object sizes may very well have to be malleable
on a struct-by-struct basis. You'd have to double up the number of
equates and have to create a special equate *for each structure* in
order to control this sort of stuff. In HLA, two extra constant
declarations (equates) is all I would need in order to control *all*
the record alignments in a given program. Sorry, your equate scheme
wouldn't do this.

For more information about record alignment, feel free to read:




> Now I am beginning to understand why Betov just
> calls you an *** and be done with it. You are asking for insanities
> while offering no work on your part this far, you are just an old very
> very sad fart, just sitting there on your so high horse, asking me to
> prove a bunch of stuff that is completly redicolously trivial to do
> with RosAsm.

Thus far, the only point you've proven is that you really don't
understand what's being asked of you. I point out that equates just
don't work and you respond with a rearranged version of the equates
that suffer from the same problem.

> You are just using my willingness to educate you.

Thus far, the only thing you've taught me is how immature you are.

> You are
> manipulating me. You are using my goodwill

You have goodwill?
Are you not the same person who was wishing me dead last year?
Are you not the same person constantly swearing at me?

> in offering clear and simple
> examples, - againts me;

The problem is that you simply don't even understand what's going on
here. Apparently this discussion seems to be well above your current
level of thinking. Again, I would point out that I pulled the *same*
tricks you're trying way back in the late 1970s on the 6502. It's not
like you have to educate me or anything, I've already been down that
path. I'm quite aware of what you can do with equates. I'm also quite
aware (based on my experiences with the PC532 assembler) of what you
can do with "pseudo-structs" like the ones that NASM and FASM generate.
And I came to the conclusion that real structs are the only way to go.
Apparently, a lot of people (Like the OP) agree. Otherwise, we wouldn't
see structs being used that much in assembly, would we?

As an interesting aside, one of the most common complaints I hear from
HLL programmers for not learning assembly is that "assembly doesn't do
structs." Products like RosAsm (and Gas) propagate that misconception
and act as yet another roadblock to people learning assembly.


> to exhaust me, while you are offering nothing
> but your useless trivial insanities.

You always have the option of not responding, not reading, and going
off and being quiet.

>
> Well. For this one time, I do not mind. As I have allready bitten the
> Trollbate, then lets continue.

Shucks. Just as I thought this newsgroup might be in for some more
peace and quiet.
Then again, what did I expect. It's not like you were ever quiet before
you recent absence.

> And I will for the future, just direct
> you to this post, when you are trying to Troll over this topic the next
> time. In order to offer alignment of members using equates, just add
> some alignment equates.However, in well planned data, this is likly to
> never be needed.
>
> [Smallpoint.AlignToDword 1]
>
> [smallpoint.x 0
> smallpoint.y 1
> smallpoint.z 2
> ______________________
> SizeOf_SmallPoint 3 + Smallpoint.AlignToDword]
>
> This makes sure all structs of this "type" are dword aligned.

Manually adding padding is *not* the solution. What happens when you
don't know the sizes of the fields? (i.e., when they're structs,
arrays, arrays of structs, etc.) Furthermore, this is hardly
maintainable. When you add fields, you've got to constantly recompute
the padding value (manually).

Further, you missed the real point of the question, which is adding
padded *between* the fields to automatically align them based on their
size and the alignment requirements (e.g., the Intel ABI). Sure, you
can manually compute these values and stick them into your equates, but
that's not *automatic*, now, is it?


>
>
> " Being able to compute the size of the
> struct/record. "
>
> Done allready, see above. The "SizeOf_Record2" computes the exact size
> of the complete structure.

You really don't get it, do you? The point is to avoid having to write
an equate to manually compute this sort of stuff. The problem with your
equates scheme is that it is not maintainable. No matter what you do, I
can modify the "struct" you create in such a way that the size is not
properly computed. That's why it's nice to have true structs and a
compile-time operator what will compute the struct size, no matter what
you've done to it.


>
> "Being able to compute the size of individual fields of
> the structure. "
>
> Allready done, Troll.

Automatically. Not by issuing an equate for each different data type
you can use as one of the fields.

>
> "Being able to create compile-time struct/record
> constants."
>
> Hehehe. How are they treating you on the nursyhome? Not too well I
> hope.

IOW, you don't even know what these are. Well, let me suggest that
RosAsm has no way of doing this. In HLA, for example, you can do
something like this:

const
someRecConst: recType[2] :=
[ recType:[ constants_for_fields_of_record],
recType:[ constants_for_fields_of_record]
];

static
someRecConst : recType[2] := someRecConst;

Of course, the assembler immediately reports an error if there are any
problems with the values in one of the fields of the record.




>
> "
> Being able to merge two struct/record declarations (i.e.,
> "inheritence"). "
>
> << i,e, inheritance>>. :))) About your inheritance... :)) Not much to
> inherit I think.
> Every piece of code I wrote, in that link is Object "trees" built from
> equates.

Yes, we've established that RosAsm can add two constants. Now show us
inheritence.

>
> "These are *some* of the advantages of true
> structs/records over equates and the automatic offset generating scheme
> that assemblers like NASM, FASM, and my 32000 assembler employed. Oh,
> and type checking, as appropriate, is pretty darn good, too.
>
> Sucker. We are left with what? The only "advantage" is the "type
> checking"

You really don't know, do you?
Oh well, keep on writing "megas" of code. Someday you'll figure out the
problems with the approach you're taking.

>
> JUST AS I SAID.
>
> You have yet again been defeated in debate.

I'm sure that in your mind you truly believe this :-)
Now convince someone else who uses structures that your equates system
is superior to actually having structs. Thus far, you've not been to
successful. Why don't you explain to the OP how he can use equates in
place of structs in his Gas code and see if you can convince him that
your way is much better?

> You will allways be
> defeated, because you have no substance to your deleriums. You are
> indeed an insignificant ***.

I'm sure you truly believe this :-)

> How anyone could ever been fooled for so long by you is a mystery to
> me.

That is a mystery!
Why is it that thousands of people are learning and using HLA, praising
its virtues, and assemblers like RosAsm that don't support facilities
like true structs/records are going unused?


> They must simply all be crackpots ! The whole x86 ? I be damned, but
> not surpriced by now. If they belive your *** they must be.

Why yes. The whole world is wrong and you are right. They are crackpots
indeed!

>
> > This is a huge advantage to equates over
> > structures, as type checking is just another name for braindamage.
>
>
> "Perhaps you would care to elaborate. How does type checking prevent
> you
> from doing what you want to do? "
>
> Well, take a look at the source code of previous versions of Delphi.
> You will see stuff like for instance TypeCasts of Rectangles to Points.
> (and many others). In the .NET version of Delphi, typecasts are
> considered ivil and is not allowed. In order to have "valid" Delphi
> code, typecasting is prevented. (I belive I read this somehwhere in the
> Delphi docs) Thus, theese type checking stuff limits you.

Exactly how does it limit you?
Perhaps you ought to consider designing your data structures right in
the first place? If you're constantly casting the types of your data
structures, you're doing something wrong. Now I stopped upgrading to
the latest and greatest with Delphi 5, so maybe something changed
radically in 6 & 7 that forced you do to typecasting all over the
place; but back in Delphi 5 I *rarely* recast anything unless I was too
lazy to design it right in the first place.

Based on your past comments about the operation of lists in Delphi, I
suspect that the reason you've done a lot of casting (if that is the
case) is because you really didn't know how to do it right in the first
place. There are some legitimate times for type casting, but if you've
come to assembly language because you want to be able to cast all your
objects ten different ways from Sunday, then I'm afraid that your
earlier comments about writing "very well structured" assembly code
have just been disproven. The whole point of structuring code is to
apply *discipline* to your coding style in order to improve the source
code. You don't achieve that by implicitly using data types in
different ways than they were declared.

> All advanced
> HLL programmers uses much typecasting, because they know more of whats
> going on, and it helps them do what they need right there.

I'm afraid you don't speak for all advanced HLL programmers. And even
if you did, how would they be any different from assembly programmers
in this respect? Are you claiming you're *not* (implicitly) type
casting in assembly? The fact that you don't have to use an operator to
achieve this does *not*imply its absence.

>
> If they had use Rosasm, they would have avoid the extra typing.

Then again, they wouldn't have structs, either :-) Or many of the other
things they expect in a programming language.

> which
> is actually defeating the type checking dementia.

Ah yes. Wannabee has just rolled back 40 years of software engineering
that has taught us that type checking is a good thing. Remember your
comment that you never make unverifiable statements? How about the one
above? Prove this statement is true. Prove that type checking, on the
whole, is bad. Sure, there are some times when you really do need to
override the type of some object. That should be rare, however. If
you're doing it a lot in your code, then there is something wrong with
the way you design code. And if you've escaped to assembly language in
order to free yourself from the tyranny of having to *explicitly* type
cast, well, don't ask me to read your code.


> So, in order to have
> "less" (as seen from your views) they write more. Asmers write less to
> begin with.

Probably because the lack of features like structs makes them spend so
much type writing equates that they don't have enough time to write
more "code" :-)


> What HLLers make of "tricks" and think is "really cool", is everyday
> boring stuff to asmers.

Show me how to implement C++ templates and meta programs in RosAsm. C++
programmers think these things are really cool. I'd like to see how you
do this with RosAsm. If it's everyday, boring, stuff, it should be
pretty easy, right?


>
> > Here is how easy it is to build scalable class objects and records from
> > equates:
>
>
> > [SizeOf_Byte 1
> > SizeOf_Word 2
> > SizeOf_Dword 4
> > SizeOf_Integer 4
>
>
> > SizeOf_Float SizeOf_DWord
> > SizeOf_Single SizeOf_Float
> > SizeOf_Double (SizeOf_Single*2)
> > SizeOf_Extended 10
>
>
> > SizeOf_Pointer SizeOf_Integer

So your code is not 64-bit clean all of a sudden. Assuming that a
pointer is the same size as an integer is the most *common* mistake
programmers have made in the past. You might claim that you only have
to change one line of code. But given RosAsm's lack of software
engineering capabilities (i.e., the "cut and paste" mentality), you
wind up having to go find this equate in every file you've created. Not
a happy day.


> > SizeOf_ObjectPointer SizeOf_Pointer]
>
>
> "What on earth do you need all that stuff for? "
>
> You call this "all that stuff" ?

I call it completely unnecessary. Why can't your assembler tell you
what the size of a variable is? Here's the major problem with your
code. You start off with something like this

[aVariable B$ .... ]

and in other places you "compute" the size of your variable with a
statement like

mov eax SizeOf_byte

Okay, cool so far. But then one day, you decide to change the variable
declaration to something like

[aVariable: W$ ...]

Alas, you've got to manually locate *all* those places you've used
"SizeOf_byte" to mean @size( aVariable) AND ONLY THOSE INSTANCES! (that
is, you can't do a search and replace operation because SizeOf_byte is
actual the correct value in most instances.

Now you *could* double all the statements in your variable declarations
and enter things like:

[aVariable B$ ...]
[sizeOfaVariable 1 ]

But now you've double the amount of code you write. No wonder you're
producing "megas" of code!

It's so much better to simply be able to ask the assembler "what is the
size of aVariable" and have it tell you. This isn't something you
should have to do yourself. All decent assemblers (e.g., FASM, MASM,
TASM, HLA, etc.) provide this capability. The fact that you have to
manually maintain this stuff yourself in RosAsm speaks volumes about
RosAsm.


> After all the rubbish you post in this
> NG. You're poser.

Subtract all the responses to people like yourself and Rene, and tell
me again about the "rubbish".


> You dont even write your own stuff in asm.

Really? Then who ghost writes all that stuff for me?

> Its
> patetic. Compared to me, who just begun writing asm, you are a
> disgrace.

As you never make unverifiable statements, prove this.

> Compared to other assembly writers, you're the joke of all
> times.

As you never make unverifiable statements, prove this.

> "Art of Assembly" beeing associated with you is a no end
> laughing matter.

One of the two most popular assembly books of all time. And you wonder
why all the x86 people disagree with your feelings on the subject?


>
> "Doesn't your assembler provide the ability to *tell* you what the size
>
> of a data object is?"
>
> I dont need to be told such simple things.

:-)
Yes, and I remember B_U_ASM telling us all that the assembler shouldn't
even have to compute simple constant expressions, that programmers can
use a calculator for that, too.

You really don't understand how this kind of stuff can make your code
more maintainable, do you? Boy, you really *are* a beginning
*programmer*.


< In fact, I dont want my
> assembler to tell me stuff,I want to tell the assembler what it can do
> for me.

Well, then you're using the right product :-)

> Not having it tell me what it
> wants me todo. But, I know what your really mean, and have shown you
> how to do it with the simple equates. Are you admitting you are unable
> to understand their purpose?

For the third or fourth time, I did *exactly* this back in the 1970s. I
learned from that experience. Now I know better.

>
>
> "The above is a maintenance nightmare; "
>
> Only in your fantasy. I have no problem maintaining a 2 mega source.

Now the *real* question is: "how would someone else deal with your
code?"
Readability *isn't* about how readable your own code is to you, but
about how readable *other* people find your code. Now there is no
question that using equates is *far* better than encoding magic numbers
throughout your code; it's good that you've managed to move this far in
your programming experience and that you're discovering the joys of
using symbolic equates for such numbers. Now the next step is for you
to learn how to use programming tools that automatically generate these
numbers for you, so you don't have to maintain them yourself. That,
plus learning how to use language facilities like structs/records and
classes to avoid the kludges you're currently writing.


> Not an inch.
> I may write some wrong code. now and then. And even some redundant one.

:-)

>
> But I have no problem organizing where to put it, how to find the code,
> and how to change it.

Again, you miss the point of maintainable code. The real question is
"can someone else maintain it?" or "Can someone else find it?" and
"can someone else understand the organization?"

> This is exceptionally easy and efficient to deal
> with in RosAsm.

In one program source file, perhaps. But what happens when you've been
cutting and pasting your "windowless gui library" into several
applications and then you find a bug in the underlying code? Whoops!
Cut and paste strikes again.

> I can start expanding my stuff at any point in the
> source, at once. No mantenance nightmare exists!

Someday, little grasshopper, you will grow to the point where you
understand the errors of your ways. In the meantime, continue cutting
and pasting all those equates. Sooner or later you will finally figure
out the problem with your approach. It's far better not to have to
change *any* statements rather than having to go back and readjust your
equates lists, no matter *how* easy you think those changes are.

> Before you cast such
> villain claims,

Why blame me? Software engineers have been decrying this kind of
programming methodology for nearly four decades. I'm sure they're part
of the "2 million" rather than the "2000", but at some point or another
you're going to discover that there is a reason software engineers warn
against these types of programming practices.

If you really think you're on to something, try posting your ideas to a
software engineering newsgroup and see how well they fly there.


> maybe you could point out this nightmare first. But
> with people like you, evidence, examples, neat explainations, its all a
> useless waste!

Been there, done that. You think you're telling me something new?
Sorry, I made those mistakes nearly 30 years ago and I don't need to
repeat them just because you've recently discovered equates.

> Of course, I do not deny you could find examples of code
> that is a nightmare, I know of a few places. But those are not
> maintance nightmares, but rather because of lacking documention and
> unanswered questions, I have stopped developeing those areas, until I
> find the propper answers to my questions, or until I find the right
> moment to finalize.

And one thing you'll probably discover is that as you put this stuff
off, the less readable your code becomes. I.e., when you come back to
your code in one year, how readable will it be at that point? Two
years? More? A clue is this: how well can other people read your code?
In time, that's about how easy *you'll* find your own code to read.


>
> "subject to problems like typographical errors and changing program
> requirements. "
>
>
> Bullshits.

So if you type
[sizeofByte 2]
instead of
[sizeofByte 1]
this won't be a problem?

@size(byte) always returns the right value. Everywhere you use it.

And as for changing program requirements, I've already discussed that
issue here (where you use SizeOfByte throughout your program to get the
size of some byte field, and then you decide to change the size of that
field to a word).

> Yet another of your insanities.

Yes, having the compiler compute all this stuff automatically for you
is insane. It's much saner to manually specify these values yourself.
How could I have been so mistaken?

> Did they surgically OPERATE
> all this stuff into your head?

Must be. I can't think of any other explanation. Other than the fact
that nearly 30 years ago I was writing code the same way you're doing
it now, and I've managed to learn from my mistakes. I guess it will
probably take you 30 years to reach that point at the rate you're
going. At least I wasn't so bold as to argue with those who had 30
years' experience on me and tell them they were insane. Granted, there
were many times when I *thought* I knew better than them (and I was
generally proven wrong, over time), but I wasn't so bold as to argue
with them about it, especially when other people were saying the same
thing.


>
> "
> Who, for example, is willing to guarantee that "SizeOf_Integer" is
> always going to be "4"?
> "
>
> Stupid cow.

Can't make a solid argument, so personally attack your opponent, eh?

> Yet again the talking head is reminding me of his past,
> present and future mistakes.

Actually, yes I am. I admit I've made this mistake in the past. I've
learned from my mistake. Better to let the compiler compute the size of
these objects rather than hard coding them into your program. Too bad
your compiler doesn't do this for you

> Delphi made us a some small headache with
> the oncommming of EVERY SINGLE version of it. SO *** you "patetic
> clown". Well put anyway. :))

You write code like you're describing and you have the nerve to blame
Delphi?
Well, I guess the good news is that someday you will be blaming RosAsm
(and rightly so) for not providing you with the tools to avert your
next disaster.

>
> "Much better to use some facility like "@size(
> integer )" and let the assembler compute this for you each and every
> time you compile the program. "
>
> Thats not in any sense "much better". Thats redicolous. The equates are
> doing this
> for free.

Adding lines of code to your program is not free. Putting in statements
that you will have to change later on, when program requirements
change, is not free.

> Its the exact same ting in fact, only more obvious to
> understand in RosAsm.

Sure. Only because RosAsm doesn't support any facilities for
automatically computing the object's size for you. You are *forced* to
use equates because of the limitations of your tools. But don't try and
tell us that this is an advantage of the tool; it is not.

>
>
> "That way, if you ever decide that an
> integer is two bytes, or eight bytes, you don't have to seek out
> equates like the above and change them. "
>
> Why would I need to "seek" it out. I know exactly where I put it, and
> it is two clicks away.

In how many different files?
And how does that help you change only the occurences of "sizeOf_Byte"
that apply to a particular field in one of your "structures" (and none
of the other fields)?

>
>
>
> > Records
>
>
> > [Point.X 0
> > Point.Y Point.X + SizeOf_Integer
> > _________________________________________
> > SizeOf_Point Point.Y + SizeOf_Integer]
>
>
> "
> Ugh!
> Now create an array of points.
> "
>
> *** yourself. You're in no position to demand me anything. You're a
> fucking faint shadow of an idiot.

I never was in a position to demand anything of you. You've simply
obliged. :-)
But if you're going to make claims like "every statement I make is
verifiable" I do believe it's fair to call you on your claims.

And I still want to see an array of points. Not an array of bytes that
you use manually created equates to determine the size of each element
of the array with.

By your argument, I could just do this in MASM:

myArray db 256 dup (?)

and claim I have an array of 32 points. If you want to know what
ridiculous is, well, making such a claim is ridiculous.


>
> "
> Create 25 different point variables.
> Incorporate the point data type into some other record.
> "
>
> Someone shut up this poor fck?

Go ahead. I want to see 25 different point variables. Not an array of
25*sizeof point bytes, but 25 separate point variables. And not a set
of 25 eight-byte arrays.
It's obvious you don't understand the difference, so go on with your
profanities and personal attacks. I can understand why you're so
frustrated as you don't have a clue what's being discussed here.

>
> "
> Oh, and then change the definition of what a point is so that it's a
> three-dimensional object (x, y, z) and let's discuss what you have to
> do to your program to fix it. Contrast this with:
>
>
> type
> point:record
> x:integer;
> y:integer;
> endrecord;
> "
>
> yes?
>
> [point.x 0
> point.y point.x + SizeOf_integer
> _________________________________________
> SizeOf_Point point.y + Sizeof_integer]
>
> Just as clear, same functionality.

Not at all. If I want to add a Z field, here it is:

type
point: record
x:integer;
y:integer;
z:integer;
endrecord;

I don't have to worry about updating SizeOf_Point. That happens
automatically when you use @size(point). You have to change a minimum
of two lines, and sometimes *three*. That's three times the work of
using a system that has true structs/records.

>
> "
> // You want an array of points?
>
>
> static
> arrayOfPoints: point[8];
>
> "
>
> ah, now we are talking. You are actually offering something
>
> [arrayOfPoints: b$ 0 (8*SizeOf_Point)]
>
> Just as clear, same functionality.

No, not as clear. and not the same functionality.
I can write @size( arrayOfPoints ) and get the size of the whole array
(e.g., for MOVSB). You have to add yet another equate to achieve this.
And, of course, the correctness of your declaration depends upon the
correctness of your equates in the point definition. There are no such
dependencies in the struct/record approach.

And then, there is the ever present issue of type checking. You can't
create an instruction like "mov arrayOfPoints al" when your assembler
knows arrayOfPoints is actually an array of points rather than an array
of bytes. Quit helpful, btw, when you've changed one of your fields
from byte to word (or some other different sized type) and you need to
search through your program and find all the places you've used the
wrong register size.


>
>
> "
> // You want to create multiple point variables?
>
>
> point1:point;
> point2:point;
> point3:point;
>
> "
> [
> Point1: b$ 0 #SizeOf_Point
> Point2: b$ 0 #SizeOf_Point
> Point3: b$ 0 #SizeOf_Point
> ]
>
> just as clear, same functionality.

If by functionality, you mean you've allocated the same amount of
space, perhaps. But there's a lot more to structs/records than space
allocation. Again, you're missing the whole point.

> But I would not do it like that!
> If I did, if I had to, I would write the first by hand, copy and paste
> it, and change
> the duplicate '1's to 2 and 3. Just as simple to do.

Yes, we know you do a lot of cut and paste coding. That's how you've
written "megas" of code, no?

> "
> You just can't do that with equates."
>
> Bullshits.
>
> Show me your hand, and I show you mine. No *** that, here is mine:
>
> [point.x 0
> point.y point.x + SizeOf_integer
> point.z point.y + SizeOf_integer
> _________________________________________
> SizeOf_Point point.z + Sizeof_integer]
>
> I just duplicated line 2, and changed y to z, and x to y, and the y to
> z in the last line.

I just added one. And that's just in the creation of the record. We've
not even begun to talk about maintenance (actually, I've mentioned the
problems several times over here, but it's probably gone right over
your head).

Also, there's more work if you decide to insert a field *between* two
existing fields. Still the same amount of work (add one line) if you've
got true structs.

> "
> Oh, and by the way, notice that
> *none* of these facilities have *anything* to do with type checking.
> "
>
> Correct, and I have with no problem, showed ALL that I claimed.

No. You've not shown anything that was obvious before. Do you think I
don't know how equates work? Again, I've done this kind of sloppy
coding in the past. Someday, you'll discover the errors of your ways.
Clearly, you're to proud to even consider the fact that there are some
fatal flaws with your approach, but someday you'll grow beyond this,
hopefully.


> You
> have not even a single proof to any of yours. In fact, you every claim
> in this post, (as well, I might add), has been completely defeated.

You've still not created a struct. You've created a set of equates that
have to be manually maintained. Every example you give, you demonstrate
how to manually maintain those equates. You've not shown me how to
automatically do this with your scheme at all (which you can't). I do
believe you've completely missed the whole point.


> Your only point, still, is the "type checking". But then again, thats
> uncalled for anyway.
>
>
> > [Rect.Left 0
> > Rect.Top Rect.Left + SizeOf_Integer
> > Rect.Right Rect.Top + SizeOf_Integer
> > Rect.Bottom Rect.Right + SizeOf_Integer
> > _____________________________________________
> > SizeOf_Rect Rect.Bottom + SizeOf_Integer]
>
>
> > ___Some Aliases when passing rects to function wanting a point
> > [Rect.TopLeft 0
> > Rect.RightBottom Rect.Top + SizeOf_Integer]
>
> "
> Unions are a better solution.
> "
>
> This actually is a union. Written with a diffrent syntax.

No, it is an equate that creates an alias. Ultimately, the semantics
may be the same, but you've *not* created a union. Again, there is a
maintenance issue here that you're doing a lot of hand-waving on.
Unions are a better solution.


> The wonderful thing with equates, is you can have as many unions,
> aliases
> and packages as you like.

And this is wonderful why?
And what prevents you from having as many unions as you like when you
actually use unions?


> I could subdivide using types decleared at
> diffrent
> times somewhere else.
>
>
> Like this
> [Rect: b$ 0 SizeOf_Rect]
>
> [HiWord 2
> HiByte 1]
>
> mov eax Rect
> mov b$eax+TRect.Left+HiWord+HiByte 100
>
> Resulting memory looks like this "64000000" or "00 00 00 64" if you
> like.

And why can't you do this in a more structured way with unions?


>
> Equates can do *any* job a structure could do,

If you mean "provide access to a field" then you're absolutely correct.
Heck, you don't even need equates, you can achieve this with literal
numeric constants. The problem with equates is that they are not as
maintainable as true structs and unions. You don't seem to understand
the concept of maintainability. You seem to think that cut and paste is
an acceptable solution for maintaining code. Some day, you'll discover
the problem with that approach. God help you if you ever try this
approach with a professional programming team -- they toss you right
out.



> and even some that
> structures cannot do. You cannot lend members of other structures to
> offset this structure member.

Whatever gave you that idea?

> But we can do this with equates.
>
> I can for instance write D$ARect + point.Y , or D$ARect + Rect.Top
> You cannot do that with your records members.

That's what unions are for.

>
> Equates can form any part of both simple types, records and also
> classes and objects. Plus they can be used to size and count the bytes
> of composite types. And thus be used to order memory for the data. They
> UNIFY all the HLL structures.

Sure. Use a hammer for every job you come up with. I'm sure even Rene
can tell you that this isn't the wisest idea. There's a reason why we
have structs *and* unions for example. It makes your code clearer when
you *explicitly* state what you're trying to achieve. Equates obfuscate
this.


Oh well, your post is putting Beth to shame.
I'll have to finish up later.
Other stuff to do now.
Cheers,
Randy Hyde

.