RE: Re[2]: [colorforth] DOES> How is colorForth different from ot her Forths?
- Subject: RE: Re[2]: [colorforth] DOES> How is colorForth different from ot her Forths?
- From: Frédéric DUBOIS <frederic.dubois@xxxxxxxxxxxxx>
- Date: Tue, 16 Dec 2003 13:22:09 +0100
> -----Message d'origine-----
> De : Jeff [mailto:jma@xxxxxxxxx]
> Envoyé : lun. 15 décembre 2003 05:37
> À : Mark Slicker
> Objet : Re[2]: [colorforth] DOES> How is colorForth different
> from other
> Forths?
>
>
> Hello Mark,
>
> Sunday, December 14, 2003, 8:58:28 PM, you wrote:
>
> MS> On Sun, 14 Dec 2003, Samuel A. Falvo II wrote:
> MS> Is a structure not simply a contiguous collection of named fields?
>
> MS> : field0 ;
> MS> : field1 1 + ;
> MS> ...
>
> Yes, but I very much frown upon hard-coding of data sets. For example,
> in my example above, I could have various FIELD(s) dictating the size
> of the member variable, and as you suggested, load based on that size,
> too:
>
> : CVAR ( n -- n+1 ) dup create 1 allot 1+ does @ + c@ ;
> : HVAR ( n -- n+2 ) ... ;
> : VAR ( n -- n+4 ) ... ;
> : DVAR ( n -- n+8 ) ... ;
>
> So, why not just make your fields like above? What happens a month
> after my product is released and I find that field2 needs to be 2
> bytes larger than it is? All other fields suddenly become a mess!
> I could have just altered one word in the code and poof -- all fixed.
>
: field0 ;
: field1 [ 0 field0 cell+ literal ] + ;
: field2 [ 0 field1 2 cells + literal ] + ;
: field3 [ 0 field2 64 chars + literal ] + ;
Now if field1 becomes two cells wide that's fine.
Amicalement,
Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com