+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Any better way around Duplicate Definition problems? (/showthread.php?tid=3413)
Pages:
1
2
Any better way around Duplicate Definition problems? - Pete - 01-23-2025
So while making some routines into libraries we have this common problem when arrays are involved, which is...
How to use an array in the main or calling routine without having to stick a REDIM a$(0) in that routine.
In other words say we need a$() in the calling routine and the library we are going to add for that routine like a mouse routine.
Main:
mouse x, y, a$()
Sub mouse (x, y, a$())
Static initiate
If initiate = 0 Then
initiate = 1
ReDim a$(_Height)
End If
End Sub
Now this will fail with a Duplicate Definition error, because a$() is being introduced as an array to be passed into the mouse sub, and therefore it must be initially defined in that calling routine, before it is passed.
So we have this, which will work...
Main:
ReDim a$(0)
mouse x, y, a$()
Sub mouse (x, y, a$())
Static initiate
If initiate = 0 Then
initiate = 1
ReDim a$(_Height)
End If
End Sub
...but we have to remember when we make the mouse routine part into a library, and use INCLUDE to add it to the main program, we also must remember it manually add the Redim() code in the calling procedure or make a companion library bi file that needs to also be included to add the needed Redim() statement in the main.
So am I missing any other library making alternatives here? If not, I feel a bit more compelled to just work with Shared arrays in a bi file, instead of passing them at all.
Pete
RE: Any better way around Duplicate Definition problems? - RhoSigma - 01-23-2025
Simply replace the ReDim a$(0) under the Main label (or whereever the first definition of the array appears, maybe in a .bi file if it's for a library) with a Common Shared a$().
As example take a look into my libraries collection, sub-folder "RS-Includes" in files "memory.bi/.bm", here the used array "gpMemory&&()" is COMMON SHARED in the .bi and the routines in the .bm file use it and REDIM it as required.
RE: Any better way around Duplicate Definition problems? - Pete - 01-23-2025
Hi Rho,
Yes, Dim Shared or Common Shared are the alternatives I mentioned. I expect I will end up with 2 INCLUDE statements, a bi and bm if I go that way. Thanks for the links. I'll have a look.
For those who haven't done multi-modular programming in qbasic days, Common Shared used to share variables across all modules where Dim Shared did not cross over into the separate modules. Multi-modular programming was a neat trick, back then, to raise the 64k limit of a program. In reality around 56k or so was the maximum you could squeeze into a single program or "module" but if you combined 4 of those, which was around the max you could combine, you could get into the 200K zone. I miss the old days... like I miss the Spanish Flu.
Pete
RE: Any better way around Duplicate Definition problems? - bplus - 01-23-2025
As I recall back in the day the bi was one, no additional added separate file (.bm is convention) for the routines to be added after main was needed. So now we split what did go into a .bi into a .bi and .bm, so the Common Shared for the array should NOT be anything new or any great chore in my way of seeing things. That you could get by without a .Bi these days is just plain luck.
Yeah all those Declares, good riddance!
RE: Any better way around Duplicate Definition problems? - SMcNeill - 01-24-2025
I guess you could always try something like this:
Code: (Select All)
SUB Foo (o AS _OFFSET, start, finish, data_type AS STRING)
DIM AS _MEM m, m1
SELECT CASE data_type
CASE "LONG": element_size = 4: mem_total = (finish - start + 1) * element_size
CASE 'others
END SELECT
m = _MEM(o, mem_total)
SELECT CASE data_type
CASE "LONG": DIM a(start, finish) AS LONG
CASE 'others such as integer, float, single, whatever...
END SELECT
m1 = _MEM(a())
_MEMCOPY m, m.offset, mem_total TO m1, m1.offset 'copy the original array to the array a() in the sub, of the desired type necessary
'do stuff with a()
_MEMFREE m
_MEMFREE m1
END SUBThen you'd call it with:
foo _OFFSET(array()), LBound(array), UBound(array), "LONG"
And you can build your array from there.
RE: Any better way around Duplicate Definition problems? - Pete - 01-24-2025
Don't POKE the bear, Steve. Don't POKE the ******* bear!
Pete
RE: Any better way around Duplicate Definition problems? - SMcNeill - 01-24-2025
(01-24-2025, 04:50 PM)Pete Wrote: Don't POKE the bear, Steve. Don't POKE the ******* bear!
Pete
![[Image: poking-extra-credits.gif]](https://media1.tenor.com/m/a-G-aD7QgmYAAAAd/poking-extra-credits.gif)
RE: Any better way around Duplicate Definition problems? - Pete - 01-24-2025
RE: Any better way around Duplicate Definition problems? - hsiangch_ong - 01-25-2025
what happened to redim _preserve?
i'm missing something. go ahead. laugh at me.
RE: Any better way around Duplicate Definition problems? - Pete - 01-25-2025
(01-25-2025, 06:44 AM)hsiangch_ong Wrote: what happened to redim _preserve?
i'm missing something. go ahead. laugh at me.
Well, if you mean trying...
Code: (Select All)
test pete$()
Sub test (pete$())
ReDim _Preserve pete$(5)
End SubThat still throws a DUPLICATE DEFINITION error and it would also require a Redim pete$(0) as the first line to work, just like Redim without _Preserve.
Now I do use Redim _Preserve in several areas of my programs to increase array size and even to use something like _Height, which can be changed in resizing events, etc. It is GREAT!!! for those purposes, but sadly, is not a use in this case, unless I'm missing something.
Pete