Sample program using the new _Files$ function

[SMcNeill]

So, Steve, I've been using _BYTEs for my boolean TRUE/FALSE flags thinking that they take up less memory than an INTEGER. Is that a FALSE notion?

_BYTES are good.  Bytes are your friend, as they're only 1 byte in size.  (That's as small a chunk of data as you can store on your drive, or in memory.)

INTEGERs are 2 bytes in size, so you'd use twice as many bytes to just hold a simple True or False value.  

The issue is there's folks who somehow think _BIT is better than _BYTE, and it's not.  _BIT only has one use -- and I'd call it a very limited case use scenario -- and that's for bit packing arrays.

DIM Array(800) AS _BIT

The above would pack 800 bits into that array and store them in 100 bytes.  Your program would use less memory and the data would take up less space on disk.

The disadvantage?   It's a lot like compressing files into a zip or 7z archive.  Sure, those files are smaller, but they're useless until you extract them.  To make use of them, you've got to load them, decompress them, then reference them.

And that's basically how bit packing works.  Packing 800 bits of data into 100 bytes, which then has to be extracted, "mathed upon" to get the right bit value from the relevant byte, and then used in your program.

It's a lot of overhead in a program, and for what??  In this case, you'd save 700 bytes of memory/storage?   WOOOOOOOOOOOOOOOOooooooooo....

Without *LARGE* Arrays for bitpacking, there's just not much use for the variable type.  Definitely no use for it when it comes to storing single values, which you then compress/decompress, just to end up storing in a byte anyway.

---

I think integers and bytes are the same size on the backend, if I'm not mistaken.

INTEGERS are 2 bytes.  _BYTE is 1 byte.

Code: (Select All)

Dim b As _Byte

Dim i As Integer

Print Len(b)

Print Len(i)