Static vs Dynamic Databases

[codeguy]

The only other structure I can think of that lends itself to changing is what I call a data dictionary, where the columns of rows are defined in a separate file, usually column titles first then the start and end points of each field separately or a string of spaces with some non-space character to delimit field beginnings or even endings. This type of structure can be changed easily and extended, truncated or inserted with great facility. Beyond this, I just don't understand.

[TempodiBasic]

Hi Guys
thanks to let me learn and think about a DATA STRUCTURES.

following yours different approaches and thoughts I can think this about Static and Dynamic structures

see attachment


Thanks for feedback

[luke]

Side note: the static vs dynamic array distinction was more important in quick basic, where there was all kinds of voodoo regarding which memory segment your array was in and whether it could be > 64KB. Now days none of that matters, and the biggest difference is whether you can resize it or not.

My (un)professional opinion is that dynamically declared arrays are the bees knees and just better in every way.

[Pete]

Yep, QuickBASIC memory tricks. Running out of memory? Just use $DYNAMIC meta command to squeeze a little more code into your limit up programs. Usually programs in the high 50's to low 60K had memory issues. Multi-modular programming was a way out for larger apps. QB64 does not support multi-modular programming.

[FellippeHeitor]

Doesn't it?

[Pete]

Don't you have better things to worry about, like if Brazilians are going to elect a racist, misogynist, homophobic, xenophobic, torture supporting, gun totting, far-right military dictator as President? Or... if you're just going to stick with a normal government made up of liberal minded criminals who drive the population to vote for a racist, misogynist, homophobic, xenophobic, torture supporting, gun totting, far-right military dictator? And I thought we had it bad in the U.S.; good luck with process, which I'm sure the news here is co-opting for our own political muck-racking.

But if you do have time... Didn't Rob state he would not incorporate QuickBASIC multi-modular programming into QB64? I started grouping all my office programs into one, because of that decision he made some 7 or so years ago.  I don't see a "Load Module" command in the IDE, so I doubt it. Multi-level modules treated global variable differently, but my memory cann't recall specifics anymore. There were some advantages and disadvantages because of these differences but I recall I had to make a lot of variable changes to my modules to merge them into single programs.

Pete

[STxAxTIC]

I think Fellippe just means you can $include BI and BM files in the main BAS program, amirite?

[SMcNeill]

I think Fellippe just means you can $include BI and BM files in the main BAS program, amirite?

But Pete's talking more about CHAIN style programs, I think.

[FellippeHeitor]

Last I checked QB64 had CHAIN implemented.

I could be wrong.

[FellippeHeitor]

Also COMMON SHARED.

I could be wrong here too.

[Pete]

Clippy always used CHAIN, I never did. I transferred data in files and ran one app to another in the old days.

Multi-modular programming was a way a single QB program could be increased from a max of 64K to 200+K. I recall one of my largest was 5 50K+ programs put together in modules. The QB IDE allowed you to save and load these modules into the IDE and run the whole thing emulated. If I recall correctly, COMMON SHARED did NOT cross modules. So if you had main.bas, m1.bas, m2.bas, etc. each module could have COMMON SHARED a$ in it but it would only be shared among the subs and functions within that module. So if a$ + "Pete" in the main.bas module and a procedure in the main.bas module called a procedure in a different module, you had to remember to pass the a$ variable, or it would be lost. Anyway, Rob did implement COMMON SHARED but not multi-modular programming. Multi-modules also prevent duplicate definitions, etc. Truth be told, it allowed for sloppy programming but it was a complete blessing when I hit the memory wall back in the day.

Pete

[SMcNeill]

QBASIC Modules explained:  http://www.infinitefactors.org/jonk/modules.html

[TempodiBasic]

Yep
I remember that days in which I wrote my first (not the only?) program multimodular using CHAIN and COMMON SHARED keywords...
how many headaches until I understood that the COMMON SHARED area must be the same in the two o more files of the program.
If  you just change the order of the variables declared in the common shared this gives you so many headaches!!!

[TempodiBasic]

Hi Guys
just a little test about COMMON SHARED and CHAIN  vs $INCLUDE

if you are patient please copy and paste these code and save as named in sequence in this post

modulo1_.bas

Code: QB64: [Select]

1. 'COMMON       REM NOT NEEDED IN $INCLUDE WAY
2. DIM SHARED a1 AS INTEGER, b2 AS STRING
3. PRINT "modulo 1"
4. a1 = 10
5. b2 = "I am here!"
6. PRINT a1, b2
7. 'CHAIN "modulo2"     REM NOT NEEDED IN $INCLUDE way
8. '$INCLUDE:'MODULO2_.BAS'
9. PRINT "modulo 1" ' all this part of the code will never run IN COMMON way
10. PRINT a1, b2
11. END
12.  

modulo2_.bas

Code: QB64: [Select]

1. 'COMMON SHARED a1 AS INTEGER, b2 AS STRING       REM NO NEEDED IN $INCLUDE way
2. PRINT "modulo 2"
3. PRINT a1, b2
4. SLEEP 3
5. a1 = 8
6. b2 = "sono di ritorno"
7.  

modulo1.bas

Code: QB64: [Select]

1. COMMON SHARED a1 AS INTEGER, b2 AS STRING
2. PRINT "modulo 1"
3. a1 = 10
4. b2 = "I am here!"
5. PRINT a1, b2
6. CHAIN "modulo2"
7. PRINT "modulo 1" ' all this part of the code will never run
8. PRINT a1, b2
9. END
10.  

modulo2.bas

Code: QB64: [Select]

1. COMMON SHARED a1 AS INTEGER, b2 AS STRING
2. PRINT "modulo 2"
3. PRINT a1, b2
4. SLEEP 3
5. a1 = 8
6. b2 = "sono di ritorno"
7.  

Otherwise you can see this pictures of results to see differences among the two methods

Good Coding