Posts: 462
Threads: 86
Joined: Apr 2022
Reputation:
67
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,710
Threads: 63
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: 306
Threads: 11
Joined: Apr 2022
Reputation:
38
(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,337
Threads: 283
Joined: Apr 2022
Reputation:
180
You guys make me cry, reusing A for both string and long in the same function.
Posts: 462
Threads: 86
Joined: Apr 2022
Reputation:
67
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: 306
Threads: 11
Joined: Apr 2022
Reputation:
38
(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,562
Threads: 164
Joined: Apr 2022
Reputation:
171
Surely he suffers the suffix ;-))
b = b + ...
Posts: 1,044
Threads: 96
Joined: Apr 2022
Reputation:
84
(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)
There are two ways to write error-free programs; only the third one works.
QB64 Tutorial
Posts: 3,562
Threads: 164
Joined: Apr 2022
Reputation:
171
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,337
Threads: 283
Joined: Apr 2022
Reputation:
180
(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?
|