Qbasicnews.com

This is probably a stupid question.

How do I make an 8 byte string for any of the new
64 bit data types if I want to store the string in an array?

For an old 4 byte "Long" -- now an "Integer", I would have
MKL$(longinteger), and would store the resulting
4 byte string in an array to consume less space in memory.

Now, I want to make an 8 byte ULONGINT so I can store only the
8 byte ascii string for each element of an array to save space in
memory.

I don't see any new MK? functions for the new data types in
the keywords reference, or from searching the forum. But,
I'm probably just not looking in the right place -- help?

Dean

why would you do that ? comsum less space dude minus the null terminator and the string descriptor your saving what 5 byte's at the most.


anyways why not simple just make a byte array
REDIM array[0] as ubyte

then dim it to the size of the string and copy the string to the array.

Why do it -- First, because if I need to load 1 million i.d. numbers
into memory, I would only use 8 megs, instead of 19 megs if
they were each 19 bytes wide. Second, I was up until 4am and I
have nothing better to do today.

I need to read a string from a file that contains an i.d. number
stored as a string of digits like 1234567890123456789. So now I
want to convert that digit string to its numeric value, and store it in
an array so that it uses only 8 bytes.

First problem is if I use VAL to convert the 19 byte digit string, it
returns a DOUBLE, and gives me -2147483648, which is a
wrong number. I don't know another way to convert a "string
of digits" into its numeric value other than by using VAL.
All I can think of is to chop it up into smaller pieces and then
take the integer value VAL returns for each piece, then
combine the pieces in a formula. Seems stupid.

I guess the second problem is not really a problem (I did say it
was probably a stupid question). I suppose if I just dim the
array as an array of ULONGINT's, it will by definition just take up
8 bytes per element anyway -- duh me.

But I could still use a hand if you can think of a better way
to get the i.d. numbers from the file into an 8 byte ulongint.

Dean

MKLONGINT$ is in the CVS, for the next version.
If you don't want to build your own release from CVS, you could use an UNION

Thanks for the info on the CVS -- will wait for next release on that.
As for unions, never used them before -- just read up on them now.
Seems like a UDT except they can overlap in memory? Not
sure what that will do for me.

I'm more concerned about how I get the i.d. numbers off the
disk and into a 8 byte long int at this point. The MKLONGINT$ isn't
going to help that issue -- first I need to convert a long digit string
into an 8 byte number. A variation of VAL would be what I need.

. . . And, I just found a post by V1C that "VALINT() added, with or without suffixes the unsigned constants above 2^31 won't be saturated anymore.. wait for the next release,"

I think that will deal with my conversion issue.

Thanks for the feedback.

Dean

Yeah, there's VAL64() for longint's, as VAL() returns a DOUBLE.

VALINT() returns an 32-bit integer, VAL() used with unsigned integers above 2^31 will saturate them.

MKLONGINT and CVLONGINT was commited to CVS days ago, i may release an unstable binary version of fbc+rtlib+gfxlib for Windows, compiled every week..

Quote:... i may release an unstable binary version of fbc+rtlib+gfxlib for Windows, compiled every week..

:bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: :bounce: