BASIC strings copied to/from ASCIIZ arrays

[kawageo]

Do we have such FB command to copy a BASIC string into an ASCIIZ array?

If not, how abouit scopy() and inversely, acopy() commands?

Geo

[dumbledore]

we sort of do... it's called "byte ptr". there's an example that comes with fb, under the examples dir called "bytestring.bas". basically, to convert from string->byte ptr, use

Code:

dim bptr as byte ptr,st as string
st="a stringy thing"
bptr=sadd(st)

and for byte ptr->string, just use

Code:

dim bptr as byte ptr,st as string
test$="stuff"
bptr=sadd(test$)
st=*bptr

[Sterling Christensen]

...and best of all that doesn't copy any string data. FreeBASIC strings are already asciiz.

[kawageo]

Really? Let me see. Borrowed some code from bytestring.bas and added some more.

Code:

dim p as byte ptr
dim temp as string
temp = "HeyHoh!"
p = sadd(temp)
    
do while p[i]
    print chr$(p[i]);
    i += 1
loop
print

sleep

Yeah! Oh, boy! Try another way just like C.

Code:

dim p as byte ptr
dim temp as string
temp = "HeyHoh!"
p = sadd(temp)
    
do while *(p+i)
   print chr$(*(p+i));
   i += 1
loop
print

sleep

Goodie! Goodie! :bounce:

Geo

[Hordeking]

While this topic is open and about strings:

If I use GET to read in a file, and want to stash it in a structure:

Is this structure:

Code:

type foo
  DIM bytestring(0 to 5) AS byte
  DIM number AS integer
end type

functionally equivalent to this structure:

Code:

type foo2
  DIM asciiz as string * 6
  DIM number AS integer
end type

Let's say my data consisted of "Hello!" and the number 42.
If I GET this data into these structures, which one will be more correct? I'm used to the C way of doing it. Does FB silently account for the null zero by putting it where byte 6 should be (byte 5 being the last human readable character)?

In another way of asking, will the string look like this if I use foo2:
'H' 'e' 'l' 'l' 'o' '!' '\0'

or

'H' 'e' 'l' 'l' 'o' '\0'

or

'H' 'e' 'l' 'l' 'o' '!' (The null zero is just thrown away, this is equivalent to what would happen with type foo.)

Also, do size functions return the actual size of the string, the size of the characters in the string, the number of characters including/excluding the null zero, or what?

[Sterling Christensen]

In VBDOS they would equivalent, but unfortunately in FreeBASIC a STRING * 6 is actually 7 bytes to make room for a 6 byte string plus a null. This makes STRING * n data types much easier to use for strings than in QB, but renders then totally useless for non-string data.

[Hordeking]

So what happens if I GET data into this string? Does it only read 6 bytes, leaving the read cursor pointing at the next byte?

[Sterling Christensen]

Nope. If you GET a STRING * 6, it will actually read 7 bytes.

In FB, STRING * n data types are virtually useless for anything except null terminated strings, which is a shame - they were so much more versatile in QB, where a STRING * n was n bytes.

So if you know that the next 10 bytes in the file are reserved for a null terminated string, then you read in a STRING * 9.

[Hordeking]

Ok, I think that answers the bulk of those questions.

I essentially want to read in a set number of bytes, like a file header string with no null terminator, and compare it like a string. Apparently that has to be done like in C with a byte array.

That is kind of too bad. What exactly is the string descriptor for, then?
The biggest reason for having strings be null terminated is so you only need a pointer set to the first byte, then functions read till they hit a zero.

[relsoft]

Descriptors are just structures for strings. Strings in FB are technically "C" char type strings. which is why it's able to use C DLLS w/o any glitch. Descriptors are structures that v1c made to make strings easier to manage in FB(like QB).

Ie. It prolly stores, the pointer, length, etc.

If you plan to GET a byte then use a the BYTE data type in FB. ;*)