Posts: 730
Threads: 120
Joined: Apr 2022
Reputation:
106
I have updated the BASFILE program with the new MID$ decoding method for the warp speed increase. I also added an adjustable length& variable in the code so you can decide how long your data lines will be. The default value of 160 seems to match close to the output size of the older but slow A$=A$+ code.
- Dav
Posts: 1,586
Threads: 59
Joined: Jul 2022
Reputation:
52
Code: (Select All)
Print #2, "Function BASFILE$()"
Print #2, " DIM A$, c$, o$, btemp$, a&, j&, p&, oc&, i as _Unsigned Long, v as _Unsigned Long"
A suggestion for people (like me) who have decided to "single-mindedly" use `OPTION _EXPLICIT`.
(Just add declaration right below `Function` heading line.)
Posts: 207
Threads: 13
Joined: Apr 2022
Reputation:
52
(09-28-2023, 04:44 PM)mnrvovrfc Wrote: Code: (Select All)
Print #2, "Function BASFILE$()"
Print #2, " DIM A$, c$, o$, btemp$, a&, j&, p&, oc&, i as _Unsigned Long, v as _Unsigned Long"
A suggestion for people (like me) who have decided to "single-mindedly" use `OPTION _EXPLICIT`.
(Just add declaration right below `Function` heading line.)
But please also be consistent on type suffix usage:
Code: (Select All)
Print #2, "Function BASFILE$()"
Print #2, " DIM A$, c$, o$, btemp$, a&, j&, p&, oc&, i~&, v~&"
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
You guys make me cry, reusing A for both string and long in the same function.
Posts: 730
Threads: 120
Joined: Apr 2022
Reputation:
106
Don’t know why I did. Will clean up all the code good. Maybe sloppy coding is one of the reason I have trouble getting things working. Trying to get the base91 working right atm.
- Dav
Posts: 207
Threads: 13
Joined: Apr 2022
Reputation:
52
(09-28-2023, 06:51 PM)SMcNeill Wrote: You guys make me cry, reusing A for both string and long in the same function.
I regularly have those duplicate/triple etc. uses in my programs, no problem as all generate different variables on the C/C++ side of things.
Code: (Select All)
DIM a$, a%%, a~%%, a%, a~%, a&, a~&, a&&, a~&&, a!, a#, a##
turns into:
Code: (Select All) __STRING_A->len=0;
*__BYTE_A=0;
*__UBYTE_A=0;
*__INTEGER_A=0;
*__UINTEGER_A=0;
*__LONG_A=0;
*__ULONG_A=0;
*__INTEGER64_A=0;
*__UINTEGER64_A=0;
*__SINGLE_A=0;
*__DOUBLE_A=0;
*__FLOAT_A=0;
Posts: 3,980
Threads: 177
Joined: Apr 2022
Reputation:
220
Surely he suffers the suffix ;-))
b = b + ...
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
(09-28-2023, 06:51 PM)SMcNeill Wrote: You guys make me cry, reusing A for both string and long in the same function. LOL, that statement cracked me up.
No issues with using the same variable name with different types, but oh my goodness pray you don't have to debug code that contains these.
(Full disclosure: I am completely guilty of doing this your honor)
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 3,980
Threads: 177
Joined: Apr 2022
Reputation:
220
09-29-2023, 12:34 AM
(This post was last modified: 09-29-2023, 12:35 AM by bplus.)
I side with Steve, I wouldn't purposely do that.
Doesn't it show lack of imagination like a person that wears black all the time.
And 1 letter variables try doing a Search > Change on one of those, yikes!
"(Full disclosure: I am completely guilty of doing this your honor)"
b = b + ...
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
(09-28-2023, 07:16 PM)RhoSigma Wrote: (09-28-2023, 06:51 PM)SMcNeill Wrote: You guys make me cry, reusing A for both string and long in the same function.
I regularly have those duplicate/triple etc. uses in my programs, no problem as all generate different variables on the C/C++ side of things.
Code: (Select All)
DIM a$, a%%, a~%%, a%, a~%, a&, a~&, a&&, a~&&, a!, a#, a##
turns into:
Code: (Select All) __STRING_A->len=0;
*__BYTE_A=0;
*__UBYTE_A=0;
*__INTEGER_A=0;
*__UINTEGER_A=0;
*__LONG_A=0;
*__ULONG_A=0;
*__INTEGER64_A=0;
*__UINTEGER64_A=0;
*__SINGLE_A=0;
*__DOUBLE_A=0;
*__FLOAT_A=0;
Here's why I'd never do this:
And the code of this abomination:
Code: (Select All)
TYPE foo
foo AS STRING
END TYPE
DIM foo AS foo
INPUT "Give me an integer number =>"; foo&
foo$ = STR$(foo&)
foo.foo = LEFT$(foo$, 1)
GOSUB foo
PRINT "Foo"; foo.foo
END
foo:
foo% = ASC(foo.foo)
foo# = foo% + RND * 255
foo& = foo# MOD 256
foo$ = STR$(foo&)
foo&& = ASC(foo$) - RND * 256
foo~%% = foo&& MOD 256
foo.foo = CHR$(foo~%%)
RETURN
Now, I offer a cookie to the first person who can decipher what the heck is going on here, and explain WHY foo.foo is printing out its own "Foo" for us, when the last assigned command for it before the PRINT statement is a very simple:
foo.foo = CHR$(foo~%%)
Shouldn't this be a single ASCII character? What the heck is going on here? How'd we get this output? And could anyone trace this and debug it if there was 100 lines of other code involved here, doing other things in between this mess?
|