Bug when redimensioning multi-dimension arrays?

[SMcNeill]

Your arrays are from (0 to 5, 0 to 5), which affects them as above.  You're ust printing them from (1 to 5, 1 to 5), and that makes it seem as if values are totally scrambled or even lost.

AH CRAP, I missed the second part of your post.

My original code (that led me here) has an OPTION BASE 1 and I forgot to do that in my test code. PEBCAK. Thank you sir, that explains a lot.

So now I'm wondering if it would be possible to implement the array copying routine that you and bplus both outlined (copying to a new array) into the REDIM _PRESERVE routines in the QB64 source so that it would work as people might expect. I'm sure there are more considerations here that I'm recognizing, but has that been looked at?

The problem with adding it into the source is simple:  How do you account for all possible variations of array that a user might have?

DIM x(0 to 1, 1 to 4)
REDIM x(1 to 3, 4 to 17)    <--- Now what the heck does the source look like for this??

DIM x(-1 to 3, 2 to 14, 1 to 27, 11, apple_number, cheestos, and_frogs)    <-- and what would the source look like to handle this when its redimmed?

Just try and imagine the routine you'd have to write for that, and it'd have to allow resizing of the LBOUND and the UBOUND... on one, or more, or all indexes...  while preserving data that may or may not be the original range anymore...

We've looked at it...  blinked stupidly to each other a few times... and then said, "Umm...  Yeah.    No.   Folks can write what they need for their one specific case.  It'd be just about impossible to support fully for all use cases."

At least, I know it'd be impossible for *ME* to try and support it.  I'd get completely lost in the complexity of trying to write something that expanded for any number of dimensions, and any index range, and then resized to any other index ranges...

So we do what's really simple:   Preserve the data in the old array and simply move it into the new array.  That'll handle REDIM and PRESERVE as long as you resize only by the RIGHTMOST index.

For anything more than that, we leave it for the user to have to write their own routine to handle it.   As you can see, just something as simple as OPTION BASE 1 can really change how things look/work and perform.   For us to change the source, we'd have to account for ALL those possible changes which the end user might need -- and honestly, that's just overwhelming to even think about in this case.  

That said, if someone else wants to sit down and sort out how to do it, we're an open-source project.  We'll be more than happy to add in any additions which they come up with for the problem.  I don't imagine that it's impossible to do; but honestly it's not something that I ever think the current devs will ever work on.  It's low priority, complex as heck, and unless there's some library already made out there that one can just plug into to do this type of thing for us, I certainly wouldn't hold my breath waiting for us to do it ourselves.