REDIM takes more resources than DIM? - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: REDIM takes more resources than DIM? (/showthread.php?tid=2870) |
RE: REDIM takes more resources than DIM? - Pete - 07-17-2024 @aurel DIM arr(100) REDIM arr(1000) That would cause a duplicate definition error. Edit: To be clearer, you can do... REDIM a(100) REDIM a(1000) or... ReDim a(100) Erase a Dim a(1000) but you cannot redefine a static array, even if you try to erase it... Dim a(100) Erase a <------ WON'T WORK. Dim a(1000) RE: REDIM takes more resources than DIM? - Kernelpanic - 07-17-2024 (07-17-2024, 06:59 PM)DSMan195276 Wrote: QB64 currently allocates both regular and dynamic arrays at runtime and on the heap (never on the stack). As far as QB64 programs are concerned this distinction doesn't matter, but it does mean that if you use `ReDim` to initially declare an array (and do not resize it later) then it's functionally no different from one declared via `Dim`. I'm pretty confident this is what Luke was getting at if/when he mentioned that you could replace `Dim` with `ReDim` with no penalty.There are problems here, but why? Personally, I think it is wrong to declare an array with ReDim... that is confusing. For me, the clear line is lost. Code: (Select All)
RE: REDIM takes more resources than DIM? - DSMan195276 - 07-17-2024 (07-17-2024, 08:12 PM)Kernelpanic Wrote: There are problems here, but why? Personally, I think it is wrong to declare an array with ReDim... that is confusing. For me, the clear line is lost.I think you're getting too caught up in the name `ReDim`, it's potentially a badly chosen command name. `ReDim` does not pair with `Dim`, you can't use `Dim` initially and then use `ReDim` afterwards. Rather, `Dim` and `ReDim` declare different types of arrays, static vs. dynamic. Only dynamic arrays declared using `ReDim` can be subsequently resized by another `ReDim`. This detail is mentioned on the Wiki page for `ReDim`, though it's about halfway down: Quote:REDIM cannot change $STATIC arrays created with a DIM statement unless the $DYNAMIC Metacommand is used!(Note that it does work like you're thinking if you use `$Dynamic`, but IMO you should forget that exists and just use `ReDim`) RE: REDIM takes more resources than DIM? - Kernelpanic - 07-17-2024 Quote:I think you're getting too caught up in the name `ReDim`, it's potentially a badly chosen command name. `ReDim` does not pair with `Dim`, you can't use `Dim` initially and then use `ReDim` afterwards. Rather, `Dim` and `ReDim` declare different types of arrays, static vs. dynamic. Only dynamic arrays declared using `ReDim` can be subsequently resized by another `ReDim`.I think I know what you mean. The field2() declared with Dim is static, so of course it can't be changed. That's right, that's what it says in the reference. I wasn't paying attention. I'll take a closer look tomorrow. RE: REDIM takes more resources than DIM? - Pete - 07-17-2024 My Av-ee-tar requests a new QB64 keyword for this... _DIMITALL RE: REDIM takes more resources than DIM? - Kernelpanic - 07-18-2024 Dynamic arrays are always created when no constant value is specified in the DIM statement - but also arrays declared as COMMON are declared dynamically. OK, that's how it works. But I stick to my opinion that I have already expressed: Personally, I think it is wrong to declare an array with ReDim... that is confusing. For me, the clear line is lost. Code: (Select All)
RE: REDIM takes more resources than DIM? - Pete - 07-18-2024 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... Code: (Select All)
Pete RE: REDIM takes more resources than DIM? - Kernelpanic - 07-22-2024 (07-18-2024, 07:51 PM)Pete Wrote: 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. Code: (Select All)
RE: REDIM takes more resources than DIM? - DSMan195276 - 07-22-2024 (07-22-2024, 02:34 PM)Kernelpanic Wrote:(07-18-2024, 07:51 PM)Pete Wrote: 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. 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. RE: REDIM takes more resources than DIM? - Kernelpanic - 07-22-2024 Quote: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.I don't know what happens internally, but the way I did it is described in the QBasic Programmer's Reference. And it works. PS: And in the Quick Basic 4.5 manual; Dim and ReDim. Pretty extensive, and not that easy. |