Error when conditional REDIM()s are in same code block as DIM()

New to FreeBASIC? Post your questions here.
Post Reply
cbruce
Posts: 166
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

Error when conditional REDIM()s are in same code block as DIM()

Post by cbruce »

.
Wondering why multiple conditional REDIM()s are treated differently when they are in a different code block than their corresponding DIM()...

I get a compile error when there are multiple REDIM()s in an IF...ELSE block - and those REDIM()s are in the same code block as their DIM().... whether the DIM()/REDIM()s are together in the main block or in a function block.

Code: Select all

''' REDIM() ERROR...

dim x() as UByte

if true then
    redim x( 0 to 255) as UByte
else
    ''' error 36: Wrong number of dimensions, X in 'redim x( 0 to 255, 1 to 7) as UByte'
    redim x( 0 to 255, 1 to 7) as UByte
END IF

print
print "ubound( x, 0) = "; ubound( x, 0)
print

Code: Select all

''' REDIM() ERROR...

sub redimtest( )
    dim x() as UByte

    if true then
        redim x( 0 to 255) as UByte
    else
    ''' error 36: Wrong number of dimensions, X in 'redim x( 0 to 255, 1 to 7) as UByte'
        redim x( 0 to 255, 1 to 7) as UByte
    END IF

    print
    print "ubound( x, 0) = "; ubound( x, 0)
    print
END SUB

redimtest( )
It does not appear to be directly related to scope - since enclosing the REDIM()s in a SCOPE block still sees the compile error.

Code: Select all

''' REDIM() ERROR...

dim x() as UByte
SCOPE
    if true then
        redim x( 0 to 255) as UByte
    else
        ''' error 36: Wrong number of dimensions, X in 'redim x( 0 to 255, 1 to 7) as UByte'
        redim x( 0 to 255, 1 to 7) as UByte
    END IF

    print
    print "ubound( x, 0) = "; ubound( x, 0)
    print
END SCOPE
But there is no compile error when the DIM() is in the main code block and the conditional REDIM()s are in a SUB() code block. And the code also executes as expected.

Code: Select all

''' REDIM() WORKS...

sub redimx( rx() as ubyte)
    if true then
        redim rx( 0 to 255) as UByte
    else
        redim rx( 0 to 255, 1 to 7) as UByte
    END IF
END SUB

dim x() as UByte

redimx( x() )

print
print "ubound( x, 0) = "; ubound( x, 0)
print
.
fxm
Moderator
Posts: 12110
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Error when conditional REDIM()s are in same code block as DIM()

Post by fxm »

Once an array is sized, you can not change its number of dimensions:
- This explains the compilation errors for the first 3 examples.
- For the fourth example, since the array is passed as a parameter, the compiler can not decide (because different arrays can be passed successively to the procedure). So it is only at run-time that an error can be detected.
cbruce
Posts: 166
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

Re: Error when conditional REDIM()s are in same code block as DIM()

Post by cbruce »

So in the first 3 examples, although I have DIM'ed a dynamic array, DIM()... the compiler sees both REDIM()s (in order) in the same context as the DIM()... and since the second REDIM() is trying to change the arrays dimensions from what the first REDIM() set as a single dimension... we get a compile error.

But with the REDIM()s in a second code block (a function)... I am able to conditionally utilize either REDIM() on an unsized dynamic array that is passed as a paramenter. EDIT: And successfully work with that array.

Correct?
fxm
Moderator
Posts: 12110
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Error when conditional REDIM()s are in same code block as DIM()

Post by fxm »

But if the procedure body tries to resize an array with a different number of dimensions than the one it has, the array is forcibly erased just as the 'Erase' keyword would do. A run-time error is only generated for a program compiled with the '-exx' option.
cbruce
Posts: 166
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

Re: Error when conditional REDIM()s are in same code block as DIM()

Post by cbruce »

Ah! So even though example 4 runs without the -exx compiler option... it is just some side effect. With -exx it compiles ok, but it breaks when it runs.
Post Reply