Fixed string & string

[etko]

I'm getting strange behavior with following code in FB 0.13

Code:

Type TESTUDT field=1
    signature As String * 4
    blah      As Integer
End Type

Dim getter As TESTUDT

Open "FILE.WAD" For Binary As #1

  Seek #1,0
  Get #1, ,getter
  Print getter.signature;"<"

Close

console output is

IWAD☻ <

8 hars total with garbage, shouldn't it be just first 4 characters?

When I do following I get strange output too:

Code:

Open "out.txt" For Output As #1
g$="blah blah"
Print #1,g$
Close

result in file txt is:

%14-14blah blah

EDIT:
Same results in fb012 guess I'm doing something wrong.

EDIT:
However

Code:

print len(getter.signature)

returns correct lenght, is print allright?

[Anonymous]

hmm... this code works.

Code:

Type TESTUDT field=1
    blah      As Integer
    signature As String * 4 - 1
End Type

Dim getter As TESTUDT

Screen 13

Open "FILE.WAD" For Binary As #1

  Seek #1,0
  Get #1, ,getter
  Print getter.signature;"<"

Close
  
Sleep

if integer is placed before the string, it doesnt like 'leak' or whatever youd call that.

[v3cz0r]

If the input file wasn't saved using FB it won't work, data types are not exactly the same as in QB, doing a binary read will likely fail as the FB strings are null-terminated, integers are 32-bit, etc.

[etko]

Pfuuf this is like big limitation to me. Is it possible to have support for QB like UDTs in future (PACKED & unaligned, with fixed string being just streams of bytes)? I mean I liked QB because it was simple to read structures like WAD file directory or acces DOS DTA's directly using very simple and meaningful types:

Code:

type WADDIRENTRY
       eName As String * 8
       eStart As Long
       eLrnght As Long
end type

This type works perfectly when i GET it with pure QBasic, but when i load it with FB all I get is a mess. I even tried a field=1 keyword but the results are same.

[Anonymous]

just read them one element at a time, as opposed to the entire TYPE in one read... it might take a little longer to code but the speed gain over qb will make up for it

[v3cz0r]

Well, fixed-len's are null terminated thanks to C being the standard (no, i'm not complaining), all strings must be null-terminated when passing as parameter, doing foo( myfixstring ) would generate a crash if mystring hadn't a terminator and telling people to do foo( myfixstring + chr$(0) ) all the time wouldn't help, mainly because '\0' is not allowed in concatenations as it's the null-terminator itself. Doing a fixed-len to zstring conversion on every call would slow everything down, as a temp string would have to be allocated and deallocated and people would also complain.

So, as i said, if you use FB to save the source file, there will be no problems. Now if you can't change the source file because it's a standard/known format, well, i can be sure they load it in C, so in FB it wouldn't be harder.

[SotSvart]

v3cz0r: Could it not be an idea to add a new optional argument(something like NONULL or smth) to GET#/PUT# making fb reading one element of the time when a UDT is used?

Please ignore this if your tired of hearing of this problem(Im sure you are!) and I know you have much more importent things todo with fb, but this would make it even more simple to use fb and make it even more qb compatible... and removing new questions about this problem over and over again :roll:

[etko]

I know c is defacto standard, but that was great on QB to not be worried about that \0, as string descriptor holded lenght. It was perfectly legal back then to load data stream containing zeros into the string and work with that, I think it was an advantage. String should be string of anything not just letters.

I don't like c very much because I think it's cryptic and as an language it's stupid language (I mean by required candy for parser like ; {} or for( ) cycle thing which is ugly ) . But I understand that zero terminator is needed for compatibility with C ugly routines .

Anyway I would like to know how can I get at least packed types with that field thingy, I don't understand it... It seems to me unnecesary to rewrite something to load 1 element at the time to UDT when it can be done in one blow, even that evil c programmers load structs in one blow.

[ShadowWolf]

just use a byte array in your type to take the place of the fix legth string. then simple combin the byte array into a string with
string = string +chr$(byte(x))

[Anonymous]

well, if its going to be fixed length, like 4 or 8 bytes, then why dont you just read it into a uinteger, or a ulongint, and then just read the bytes as ascii?