dbTalk Databases Forums  

VFP Array Element Handling Gotcha

comp.databases.xbase.fox comp.databases.xbase.fox


Discuss VFP Array Element Handling Gotcha in the comp.databases.xbase.fox forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Gene Wirchenko
 
Posts: n/a

Default VFP Array Element Handling Gotcha - 02-12-2008 , 06:20 PM






I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Reply With Quote
  #2  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM






Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #3  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #4  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #5  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #6  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #7  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #8  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #9  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
  #10  
Old   
Rush Strong
 
Posts: n/a

Default Re: VFP Array Element Handling Gotcha - 02-12-2008 , 07:44 PM



Gene Wirchenko wrote:
Quote:
I just got bit in a minor way with the way that VFP handles array
elements. Consider the following code:

local twod(10,2)
for i=1 to 10
for j=1 to 2
twod(i,j)=10*i+j
endfor
endfor
? twod(4,3)

Note the array dimensions and the reference. The reference is
treated as being the third element starting in row 4 with VFP not
checking against the declared dimension. The reference is treated as
referring to twod(5,1), not as being an error.

The docs do say that 2-D arrays can be accessed as 1-D. The
implementation appears to be more general than that. Forewarned is
forearmed and all that.


The docs would be more accurate to say that 1-D arrays can be accessed
as 2-D, because 1-D is all that Fox can handle. That is, every array is
one dimensional. Declaring twod(10,2) creates the same 20 element array
as twod(20) [or as twod(5,4)]. The 2-D conceit is a logical 2-D
addressing scheme, but does not affect the actual array structure. It
appears that Fox locates twod[4,3] by locating the element corresponding
to the start of the logical fourth row by multiplying the declared
number of columns (2) times 4 - which is element number 7 - and then
moves the pointer by two more elements, to element number 9. This, as
you noted, is the result of ASUBSCRIPT(9).

The 1-D structure also explains the behavior of re-dimensioning an
array. If aFoo(3, 3) is:

1 2 3
4 5 6
7 8 9

DIMENSION aFoo(2, 2) will result in:

1 2
3 4

as opposed to:

1 2
4 5

As you said, forewarned is forearmed.

- Rush


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.