Reading the string with databuffer

About Monkey 2 Forums Monkey 2 Programming Help Reading the string with databuffer

This topic contains 11 replies, has 2 voices, and was last updated by  nerobot 8 months, 3 weeks ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #15108

    cocon
    Participant

    I try to create some binary loader, but got stuck at the point of reading strings. Say that I know nothing about the size of the string, it might be anything of unknown length. So the point here is to let the reader scan the bytes and return the string by itself.

    This code is only a sample for producing the binary file.

    #15117

    cocon
    Participant

    after lots of testing i figured it out

    Attachments:
    #15119

    cocon
    Participant

    Otherwise if you want to test the default peek string method you would see some problems:

    #15120

    nerobot
    Participant

    Otherwise if you want to test the default peek string method you would see some problems

    Even if you use buffer.WriteString() ?

    #15131

    cocon
    Participant

    I looked at it further today and I found differences on how CSharp + Monkey writes the data buffer. However I found a better way to read the string (which works both fine for the C# data and the Monkey data – hopefully would be universal). It seems that PeekCString does the work fine however there was some trickiness involved in figuring out the offsets and lengths on how the string is peeked and the pointer is advanced.

    #15137

    nerobot
    Participant
    1. You poke string but peek cstring. Is it correct?
    2. There is a CStringLength property of String type. Can be useful to set proper offset.
    #15146

    cocon
    Participant

    Buffer.PeekCString helps a lot because it stops when it detects the 0 byte.
    monkeydoc: Reads a null terminated CString from the databuffer.

    However PeekString is designed differently.
    monkeydoc: all bytes from offset until the end of the data buffer are read

     

    I tried as well PeekCString to see if it works but it gives the same number (which is 7 ).

    #15147

    nerobot
    Participant

    I tried as well PeekCString to see if it works but it gives the same number (which is 7 ).

    It is true for latin locale, not for whole utf.

    Look at this example with russian text:

    It prints: 11, 11, 10, 19.

    #15152

    cocon
    Participant

    Oh so this means that CStringLength is the raw string format, right?

     

     

    Something else, I updated the code today but still it fails. For the sake of example, I coded the data generator again in C, this is as close as it gets to what the problem is. Monkey and C# might have been better design to avoid this confusion, but C is something different. I might have to do unicode conversion or bitshifting (null bytes might be bishifted to the other bytes).

     

    No more no less I captured the output in the screenshot.

    Attachments:
    #15154

    nerobot
    Participant
    1. Maybe \0 is needed for strings? fprintf(f, "%s", "HELLO\0");
    2. Why don’t you write such generator in mokey2?
    #15159

    cocon
    Participant

    It seems that there are various conventions on how to write strings.
    http://wiki.freepascal.org/Character_and_string_types#String

    The STRING+NULLBYTE is the Ansi String (what monkey has)
    The STR_LENGTH+STRING is the Pascal String (what the file format has)

    The problem was that I had not notice what sort of strings the file format used. I got inconsistent results among Monkey+C#+C++ because of not knowing the convention. :-S

    I can add simply a ReadPascalString method to the binary reader and close this. 🙂

    #15160

    nerobot
    Participant

    Java also use STR_LENGTH+STRING (afaik).

    ReadPascalString name is not good.

    Maybe

    • ReadString – for len+string
    • ReadZeroTerminatedString – for string+0

    Would be easy to read and understand.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.