A better way to handle COMMON SHARED / SHARED ?

[Richard]

If I have say 100 variables in a program which does not use SUBs/FUNCTIONs - only uses GOSUBs - then I do not need to COMMON SHARED / SHARED.

However, if I have say 10 SUBs each with 10 variables used, and many of those SUBs can call any of the other SUBS with some amount of same variable usage between those SUBS - I currently COMMON SHARED (my 100 variables) and then for each of the 10 SUBs I SHARED (my 100 variables), knowing only a few are referenced for each SUB.

This SHARED approach "clutters' an otherwise compact SUB and if I make a typo in the SUBs SHARED variables - can cause time wasting solving problems.

Apart from $include approach for the SHARED variables in the SUBs  - is there a better way to approach this?

[luke]

I would question the need for 100 globals to begin with - the majority of data should be via function arguments.

[TerryRitchie]

There are a few ways I approach this:

1st - Using SHARED

DIM Something(10) AS INTEGER

SUB MySub()
  SHARED Something() AS INTEGER
END SUB

2nd - Using shared but with a type to move lots of information

TYPE LOTSOFDATA
    Var1 AS INTEGER
    Var2 AS LONG
    Var3 AS STRING
    etc..
    etc..
END TYPE

DIM LotsOfData AS LOTSOFDATA

SUB MySub()
    SHARED LotsOfData AS LOTSOFDATA
END SUB

3rd - Pass the TYPE in

MySub LotsOfData

SUB MySub(Stuff AS LOTSOFDATA)

    PRINT Stuff.Var1
    PRINT Stuff.Var2
    etc..
    etc..

END SUB

[TempodiBasic]

Hi Richard

sorry I'm parsing your request

COMMON SHARED 

COMMON shares common variable values with other linked or CHAINed modules.

DIM SHARED   

DIMensioned variables are shared with all procedures in the program module.
When used with DIM in the main module, it eliminates the need to pass a parameter variable to a SUB or FUNCTION.

IMHO using DIM SHARED  you needn't use SHARED into Subs/Functions or pass them as parameters.

see this example

Code: QB64: [Select]

1. DIM SHARED i AS INTEGER
2. i = 10
3. a
4. b
5.  
6. END
7.  
8. SUB a
9.     PRINT i
10.     i = i + 1
11. END SUB
12.  
13. SUB b
14.     PRINT i
15.     i = i + 1
16.     c
17. END SUB
18.  
19. SUB c
20.     PRINT i
21.     i = i + 1
22. END SUB
23.  
24.  

I hope that this will be useful!

[bplus]

If I have say 100 variables in a program which does not use SUBs/FUNCTIONs - only uses GOSUBs - then I do not need to COMMON SHARED / SHARED.

However, if I have say 10 SUBs each with 10 variables used, and many of those SUBs can call any of the other SUBS with some amount of same variable usage between those SUBS - I currently COMMON SHARED (my 100 variables) and then for each of the 10 SUBs I SHARED (my 100 variables), knowing only a few are referenced for each SUB.

This SHARED approach "clutters' an otherwise compact SUB and if I make a typo in the SUBs SHARED variables - can cause time wasting solving problems.

Apart from $include approach for the SHARED variables in the SUBs  - is there a better way to approach this?

I am not understanding the problem.

Do you know that if you DIM SHARED a variable or array at the beginning of a program then you do NOT have to use SHARED in all the subs using those variables.

Code: QB64: [Select]

1. DIM SHARED mySharedVar
2. mySharedVar = 10
3. testShared
4. SUB testShared
5.     SHARED mySharedVar ' <<<<<<<<<<<<<<<<<<< this line is not necessary
6.     PRINT "My Shared Variable:"; mySharedVar
7. END SUB
8.  

PS save yourself from lost time from typos by OPTION _EXPLICIT first line of your program, you will never know all the grieve you just saved yourself from but it's not free you pay by DIM everything!

[Cobalt]

I'm with Bplus on this. Don't really understand what your getting at.
Perhaps a little code as an example?
I mean no offense, I'm terrible at explaining things most the time myself.

[Richard]

Thanks everyone for your replies.

I was doing things the way I did with M$ PDS 7.1 (an upgrade to QB45) and at that time I did not have access to internet and forums and support groups or "experts".

Suppose you could say "old habits die hard".

Many thanks