On: The Most Expensive One-byte Mistake

[boredguy8]

And re-introduces the 'magic character' you're trying to eliminate.

[fuzzix → boredguy8]

The magic character is in a known location, there's no need to iteratively scan for it.

The use of "magic" characters is not the problem, as I see it.

[boredguy8 → fuzzix]

No it's not. In the first line, it's in [0], in the second line, it's in [1], in the third line, it's in [2]. You have to scan through to find where the '0' appears

[tlrobinson → boredguy8]

True, but it's O(log N) rather than O(N) to determine length.

BTW I'm not sure if it was clear or not but those are bits in my diagram, not bytes/characters. The "x"s are the bits of the length field, not the characters of the string.

[daemin → tlrobinson]

But you could just as easily set aside the first 4 bytes of a string to be the length and then it would be O(1).

But does that really matter when you're doing operations on the string that iterate over the whole string anyway? Since iterating the whole string is O(n) anyway, you're not really gaining anything.

[fuzzix → daemin]

Operations to return string length or return characters from the end of the string become far less expensive.

You also have a fair idea of a reasonable sized buffer to move in duplication operations, avoiding single character move loops.