Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
BASFILE - Converts small files to BAS code.
#21
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

Find my programs here in Dav's QB64 Corner
Reply
#22
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.)
Reply
#23
(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~&"
Reply
#24
You guys make me cry, reusing A for both string and long in the same function.
Reply
#25
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

Find my programs here in Dav's QB64 Corner
Reply
#26
(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;
Reply
#27
Surely he suffers the suffix ;-))
b = b + ...
Reply
#28
(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
Reply
#29
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 + ...
Reply
#30
(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?
Reply




Users browsing this thread: 1 Guest(s)