ah, so making the assignment to the scalar variable is the difference, vs an array variable. they are in different memory areas.
thanks I think that is a clear answer. On Tue, May 29, 2018 at 7:08 PM, Ken Pettit <petti...@gmail.com> wrote: > Hi Steve, > > The line: > > 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1) > > Doesn't work because you take the value of VARPTR(A$(0)) and assign it to > F. But then you assign the value of K. This creates a new scalar > variable, causing A$(0) to be moved. So then the "256*PEEK(F+2)+PEEK(F+1)" > fails because K is pointing to the old location for A$(0). > > If you change your line as follows, then it should work because K is > created first, causing A$() to be moved, and *then* you take the address of > A$(): > > 20 K=0:F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1) > > Ken > > > On 5/29/18 3:43 PM, Stephen Adolph wrote: > > Ken, when I first read your code I said "That wont work and k(0) will be > wrong." > > however it seems to work. > > I cannot explain why your code works and my original code did not. I > never modify the string content. > > ------------------------------------- > your line: > 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT > > compared with > 20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1) > > yield the same answers for K(0) > > ----------------------------------- > your line: > 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT > > compared with > 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1) > > yield different answers for K, K(0) > the only difference is using K vs K(0). > > > I still don't know a good rule for how to safely use VARPTR!! > > > > > > > > On Tue, May 29, 2018 at 4:52 PM, Ken Pettit <petti...@gmail.com> wrote: > >> Steve, >> >> Are you are trying to pre-calculate the addresses of the strings to save >> time or something? >> >> One thing to note is that the address of the A$() or D$() array variable >> will move around in RAM. However, as long as you don't modify the strings >> *in* the array after they are first assigned, then the >> "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the actual text will >> NOT change. Those addresses will be pointing back to the actual string >> text in the BASIC program (which doesn't move around during program >> execution). >> >> This is an optimization BASIC makes. When strings are first assigned, >> the variable is created with an address pointing to the actual string >> text. The initial value simply points to the BASIC program. If the >> contents of that string variable are changed after that point, then BASIC >> moves the text into high RAM to make the modification. Otherwise the text >> simply lives in the BASIC program. >> >> So you could create an array of pre-calculated addresses as follows: >> >> 10 DIM A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3 >> )="blah3" >> 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT >> 30 REM >> 40 REM Now any variable can be created and the values in K() will still >> be correct. >> >> Ken >> >> >> On 5/29/18 9:25 AM, Stephen Adolph wrote: >> >> John, I wasn't able to declare variables in any meaningful way to solve >> this problem. Only assignment seemed to work. Do you know a trick for that? >> steve >> >> On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis <jho...@pobox.com> >> wrote: >> >>> >>> On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt <bir...@soigeneris.com> >>> wrote: >>> >>>> >>> Anytime a new scalar (i.e. non-array) variable is created, the >>>> addresses of the array variables must all change to make room for the new >>>> scalar variable. >>>> >>>> >>>> >>>> So BASIC copies all the arrays to a new memory address? That does not >>>> seem very efficient. >>>> >>>> >>>> >>>> Jeff >>>> >>>> >>>> >>> >>> I think it’s a trade off. Extra levels of indirection are also >>> inefficient. >>> >>> It’s either take the hit on a “move” when a variable is created or take >>> a guaranteed hit every variable access. >>> >>> And you can avoid the cost by declaring your variables up front. >>> >>> — John. >>> >>> >>> >> >> > >
