3 ms·

For sake of simplicity, and for efficiency with really small strings, with a length-prefixed string representation you really want to keep the string length fie

For sake of simplicity, and for efficiency with really small strings, with a length-prefixed string representation you really want to keep the string length field fixed-size. In general.

thaumasiotes 4y ago
Really small strings have a fixed-size length field in any variable-size encoding of the length. They're small, so they fit into whatever the smallest possible length field is. What do you gain in handling short strings from an inability to handle long ones?
- jstimpfle 4y ago
  Ok I give you this one, but I still don't think that minimizing the size of a length field using a flexible width encoding is a good idea except when talking about extremely specialized string encodings (like compression schemes). Flexible width encoding is more complicated compared to simple member access to get at the first character. And how do you handle construction of a string whose size you don't know yet? You might have to move the string away to make space for a bigger string length field. I don't like it.
  - thaumasiotes 4y ago
    > Flexible width encoding is more complicated compared to simple member access to get at the first character. I don't think this is true either. It's almost true. But what happens if the string length is 0? If you make the assumption that you can access the first character of a zero-length string by just grabbing whatever is in memory after the string header, you're going to make the exact mistake the length field is there to stop you from making, a memory access violation. You have to process the length field in order to do any access at all; many strings don't have a first character. > And how do you handle construction of a string whose size you don't know yet? You might have to move the string away to make space for a bigger string length field. That's true; you'll either need to be willing to store the character data and the length metadata in separate locations, or you'll need to be willing to occasionally move the data around.
    - jstimpfle 4y ago
      Obviously I mean get at the address of the first character, if any. You can't load before you know that what you load is valid. Btw. zero-terminated strings allow you to load unconditionally. Sometimes that's nice.
      - thaumasiotes 4y ago
        OK, but now the difference in how complicated it is to read from the string boils down to this: 1. Read the first chunk of the string length. 2. Is it more than 0? vs 1. Read the first chunk of the string length. 2. Did we get the whole thing? 3. Is the length more than 0? That extra step in the variable-length case means checking whether a bit is set in the value you just read. --- Also, it occurs to me that this whole discussion is talking about how to serialize or deserialize a string, when the original discussion is over how the string should be represented in memory.

For sake of simplicity, and for efficiency with really small strings, with a length-prefixed string representation you really want to keep the string length field fixed-size. In general.

thaumasiotes 4y ago

Really small strings have a fixed-size length field in any variable-size encoding of the length. They're small, so they fit into whatever the smallest possible length field is. What do you gain in handling short strings from an inability to handle long ones?

jstimpfle 4y ago
Ok I give you this one, but I still don't think that minimizing the size of a length field using a flexible width encoding is a good idea except when talking about extremely specialized string encodings (like compression schemes). Flexible width encoding is more complicated compared to simple member access to get at the first character. And how do you handle construction of a string whose size you don't know yet? You might have to move the string away to make space for a bigger string length field. I don't like it.
- thaumasiotes 4y ago
  > Flexible width encoding is more complicated compared to simple member access to get at the first character. I don't think this is true either. It's almost true. But what happens if the string length is 0? If you make the assumption that you can access the first character of a zero-length string by just grabbing whatever is in memory after the string header, you're going to make the exact mistake the length field is there to stop you from making, a memory access violation. You have to process the length field in order to do any access at all; many strings don't have a first character. > And how do you handle construction of a string whose size you don't know yet? You might have to move the string away to make space for a bigger string length field. That's true; you'll either need to be willing to store the character data and the length metadata in separate locations, or you'll need to be willing to occasionally move the data around.
  - jstimpfle 4y ago
    Obviously I mean get at the address of the first character, if any. You can't load before you know that what you load is valid. Btw. zero-terminated strings allow you to load unconditionally. Sometimes that's nice.
    - thaumasiotes 4y ago
      OK, but now the difference in how complicated it is to read from the string boils down to this: 1. Read the first chunk of the string length. 2. Is it more than 0? vs 1. Read the first chunk of the string length. 2. Did we get the whole thing? 3. Is the length more than 0? That extra step in the variable-length case means checking whether a bit is set in the value you just read. --- Also, it occurs to me that this whole discussion is talking about how to serialize or deserialize a string, when the original discussion is over how the string should be represented in memory.