4 ms·

I sometimes think the C decision to encode strings as non-zero bytes was one of the worst. The other candidate is the atrocious operator precedence. OK, we no

I sometimes think the C decision to encode strings as non-zero bytes was one of the worst. The other candidate is the atrocious operator precedence. OK, we now love parens to 'fix' this -- might as well use lisp... ;-)

ilyt 4y ago
It was unequivocally one of the worst decisions in programming. I wouldn't be surprised if costs of dealing with it would be in the billions now. It occasionally saved a byte on devices with little memory which kinda made sense at a time, but not anymore
- stabbles 4y ago
  It makes perfect sense when writing and reading strings from disk, since you don’t have to worry where and how to store the integer for the length (#bytes & endianness)
  - optionalsquid 4y ago
    Wouldn't endianness be a concern regardless, unless you are literally only reading/writing (null terminated) strings? Which I would imagine to be a much rarer case than writing a mix of data-types or just plain text.
gumby 4y ago
Many systems used this convention; c was merely one of them. So it was a “choice” more than an”decision”. The Mesa guys at PARC did a study back in the late 70s and, statistically, length-marked strings are faster than delimited ones. Delimited strings have some advantages: they save the space needed to store the length, at the cost of an extra byte (not worth the cost these days); and some substrings can be assembled simply by pointing into the string (of course counted strings can share storage). But at a terrible cost. But remember that the PDP-7 was less powerful than some AVRs. We use more powerful chips to scan keyboards these days.
- adgjlsfhk1 4y ago
  You could pretty easily make it be very low overhead. Store the length of 128 or fewere byte strings with 1 byte for the length (starting with a zero), and if the first bit is a 1, then the string length takes 4 bytes (or use extra bytes with the same format).

ilyt 4y ago

It was unequivocally one of the worst decisions in programming. I wouldn't be surprised if costs of dealing with it would be in the billions now. It occasionally saved a byte on devices with little memory which kinda made sense at a time, but not anymore

stabbles 4y ago
It makes perfect sense when writing and reading strings from disk, since you don’t have to worry where and how to store the integer for the length (#bytes & endianness)
- optionalsquid 4y ago
  Wouldn't endianness be a concern regardless, unless you are literally only reading/writing (null terminated) strings? Which I would imagine to be a much rarer case than writing a mix of data-types or just plain text.

gumby 4y ago

Many systems used this convention; c was merely one of them. So it was a “choice” more than an”decision”. The Mesa guys at PARC did a study back in the late 70s and, statistically, length-marked strings are faster than delimited ones. Delimited strings have some advantages: they save the space needed to store the length, at the cost of an extra byte (not worth the cost these days); and some substrings can be assembled simply by pointing into the string (of course counted strings can share storage). But at a terrible cost. But remember that the PDP-7 was less powerful than some AVRs. We use more powerful chips to scan keyboards these days.

adgjlsfhk1 4y ago
You could pretty easily make it be very low overhead. Store the length of 128 or fewere byte strings with 1 byte for the length (starting with a zero), and if the first bit is a 1, then the string length takes 4 bytes (or use extra bytes with the same format).