3 ms·

Actually, it's 7 bytes (you can remove `\0` at the end), and that's if you insist on being able to exceed 4GB with your strings. Personally, depending on the u

Actually, it's 7 bytes (you can remove `\0` at the end), and that's if you insist on being able to exceed 4GB with your strings. Personally, depending on the use case, I'd be willing to have strings limited to 256 bytes (no overhead), 64K bytes (1 byte of overhead), and 4G bytes (3 bytes of overhead). Though combining them all might be quite the nightmare…

codesnik 5y ago
you can also have something akin to MIDI encoding with higher bit reserved to mark that next byte is a part of length field, too. up to 128 bytes with no overhead, up to 16kb with one byte overhead, and so on. Such a detail would be easy to hide in the library. But I wouldn't be surprised that alignment and other troubles would eat any possible gain.
- WalterBright 5y ago
  Won't work with UTF-8.
  - thrwaeasddsaf 5y ago
    Works with any encoding and arbitrary binary data. The last byte of the length field doesn't have the high bit set, and whatever follows after that is completely irrelevant. But still needless complexity for this.
  - moonchild 5y ago
    Sure it is, the length is out of band. In fact, you could even use utf-8 to encode the length!
- habibur 5y ago
  > But I wouldn't be surprised that alignment ... troubles would eat any possible gain. It's string. Alignment shouldn't be a problem. Rather alignment issues are for the pointers to that string.
dnr 5y ago
Don't forget supporting small strings (<= 7 bytes) in the pointer itself using tag bits. No allocation or dereferencing required.
- habibur 5y ago
  Microsoft's MFC used to do this in their first version. But later ditched it. Maybe they found it not worth the trouble of checking for this condition everywhere. Increase in code.
  - gpderetta 5y ago
    Thse days, in C++, this is routinely done in various std::string implementations (which are both null terminated and have a separate length). In fact the standard was updated to explicitly allow this.

codesnik 5y ago

you can also have something akin to MIDI encoding with higher bit reserved to mark that next byte is a part of length field, too. up to 128 bytes with no overhead, up to 16kb with one byte overhead, and so on. Such a detail would be easy to hide in the library. But I wouldn't be surprised that alignment and other troubles would eat any possible gain.

WalterBright 5y ago
Won't work with UTF-8.
- thrwaeasddsaf 5y ago
  Works with any encoding and arbitrary binary data. The last byte of the length field doesn't have the high bit set, and whatever follows after that is completely irrelevant. But still needless complexity for this.
- moonchild 5y ago
  Sure it is, the length is out of band. In fact, you could even use utf-8 to encode the length!
habibur 5y ago
> But I wouldn't be surprised that alignment ... troubles would eat any possible gain. It's string. Alignment shouldn't be a problem. Rather alignment issues are for the pointers to that string.

dnr 5y ago

Don't forget supporting small strings (<= 7 bytes) in the pointer itself using tag bits. No allocation or dereferencing required.

habibur 5y ago
Microsoft's MFC used to do this in their first version. But later ditched it. Maybe they found it not worth the trouble of checking for this condition everywhere. Increase in code.
- gpderetta 5y ago
  Thse days, in C++, this is routinely done in various std::string implementations (which are both null terminated and have a separate length). In fact the standard was updated to explicitly allow this.