REDIM takes more resources than DIM?

[bplus]

Cool, This is a good point, and something I can't quite off-hand come up with a reason why a variable can be used to avoid a numerically assigned array duplicate definition error...

I don't understand what you're trying to say. It's clear that ReDim y(7) produces an error. Dim y(5) doesn't specify a constant value.
That's how it works.

Pete's point is a good catch, which is that the `ReDim x(b)` line should produce the same error as the `ReDim y(7)` line. I assume it's just a bug, though I guess the QBasic behavior should be checked before saying that for sure.

Usage of a variable for the bounds is different from a constant because the array has to be allocated/initialized at the position of the `Dim` statement, rather than at the start of the program or SUB/FUNCTION. This is similar to how `ReDim` works, the allocation takes place at the point of the `ReDim`, and it seems like the flag indicating the array is static never gets set when allocated this way. If the flag is missing then you're allowed to do a `ReDim`, so you don't get an error.

It might have been left that way to remain compatiple to old QB, the inconsistency sure is confusing.

[Pete]

I agree. Probably kept this way for backwards compatibility reasons.

Pete

[Kernelpanic]

I can't see any inconsistency, but that may be because I've never been as involved with Basic as most people here.

I looked at the description of Dim and ReDim in the manual again... the developers of Quick Basic knew exactly what they were doing. That's my impression anyway. I don't think they saw any inconsistency in their work. For them, it was obviously the only right way. But you should also take into account the time and the hardware available.

One should leave it as it is. Who knows what will happen if one change it.

The current behavior is well described and it works. What more could you want?

[Pete]

Both Rob and Fell were big on supporting QuickBASIC legacy. I think the VAL() bug, that we could use to distinguish between different versions of QB, was an exception to that, because it was just something that needed fixing. This is more a feature than a bug, so my guess is it will be maintained as-is.

Probably the biggest missing link is no one ever tackled support for FN. I imagine converting to C would be an FN pain. If I ever wanted the few programs I made using FN to work again, I'd just have to change the FN statements to real functions. FN was a fun little shortcut to have, but I've been able to live happily without it, especially since the time went into creating so many new highly usable features. Still, it's really a credit to the early developers that they didn't get lost in new features at the expense of legacy, that so many other BASIC products of that time experienced.

Pete

[luke]

Some background context regarding arrays:

QuickBasic has two separate kinds of arrays, static and dynamic. Static arrays have their bounds known at compile time, and so the compiler can emit more efficient code. Dynamic arrays are the opposite, their bounds are not known until the program reaches the statements at runtime.

When you write DIM a(x), the compiler must create a dynamic array as the value of x is not known until the program runs. When you write DIM a(3), the compiler can be more efficient and create a static array.

Here is QB 7.1 creating and accessing a dynamic array (apologies for screenshots over text, it is awkward to get listings out of codeview):



First we must call the B$DDIM helper routine with arguments specifying lower (0) and upper (the value of x) bounds, element size (4) and number of dimensions (1). When we access an element, we first read the array lower bound from memory, add that to the index we want then finally access the array.

Whereas here is creating and accessing a static array:



Since the compiler knows the size of the array, space is already reserved for it and no initialisation is required. This is why you can't redim a static array: it has its fixed spot in memory. Because the lower bound is also known at compile time, the memory address of each element can be emitted directly.

So static arrays are more efficient, but their efficiency relies on them being at a fixed location in memory with a fixed size. Whereas dynamic arrays can be resized, but move around in memory and need extra memory accesses to calculate offsets.

QB64 does not make the same degree of optimisation regarding static arrays, but still enforces the restriction on resizing them. I suppose in the future it could optimise this, but there are probably smarter ways to do it.

PS This is one time CONST makes a difference. CONST x = 3: DIM a(x) gives a static array, without the CONST it would be a dynamic array.