Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Any better way around Duplicate Definition problems?
#1
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
Reply
#2
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.
Reply
#3
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
Reply
#4
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!
b = b + ...
Reply
#5
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 SUB

Then you'd call it with:

foo _OFFSET(array()), LBound(array), UBound(array), "LONG"

And you can build your array from there. Tongue
Reply
#6
Don't POKE the bear, Steve. Don't POKE the ******* bear!

Big Grin Big Grin Big Grin 

Pete
Reply
#7
(01-24-2025, 04:50 PM)Pete Wrote: Don't POKE the bear, Steve. Don't POKE the ******* bear!

Big Grin Big Grin Big Grin 

Pete

[Image: poking-extra-credits.gif]
Reply
#8
   
Reply
#9
what happened to redim _preserve?

i'm missing something.  go ahead.  laugh at me.
Reply
#10
(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 Sub

That 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
Reply




Users browsing this thread: 1 Guest(s)