5 ms·

Right, so you'd need a BigString analogue to BigInt for that case. Which wouldn't be that bad, really. I mean, a 64k string is plenty for your everyday string

by Dove 15y ago

Right, so you'd need a BigString analogue to BigInt for that case. Which wouldn't be that bad, really. I mean, a 64k string is plenty for your everyday string needs. And in cases where you're handling really long strings, you'd probably want a specialized data structure anyway. I mean, it's not like char* is exactly efficient when you need to insert something into the middle of a many-megabyte file.

burgerbrain 15y ago
I mean, a 64k string is plenty for your everyday string needs. No, not for my everyday needs.
- jerf 15y ago
  But the question here isn't actually "What is the ONE TRUE STRING format that the language permits, all others to be rigidly banned by the compiler?", the question is "What shall the default string be in the core C APIs and functions?" If you still need NULL-terminated strings, you could have chosen them, and if you knew enough to so choose, hopefully you know enough to treat them like the dangerous tools they are. Meanwhile, the core C functions and API and UNIX could have been built around the much safer strings, which wouldn't have been all that hard to upgrade to 4 bytes (or more) later. Or we could have done a UTF-8-like size encoding, or turn the default strings into linked lists if they got large, etc. It would be OK, because raw expanses of memory would still be available to you, it just wouldn't be the default. NULL-terminated strings are the wrong default, even though they should be available to those who really need them.
  - burgerbrain 15y ago
    Multiple string schemes is exactly the sort of fragmentation this industry does not need. Citation: C++.
    - tptacek 15y ago
      You mean, basic_string and charstar?
      - copper 15y ago
        Hm, It can be a real problem if you have the joy of working with old C++ code: the initial codebase might have had its own string type, and then some more classes added by long-gone programmers who thought the earlier types were slow, and then newer code added by people who actually use std::string (well, you get the idea). (much to my regret, that is a true story.)
dkersten 15y ago
For those kinds of tasks, a string doesn't seem all that appropriate to me. The BigString (that is, a Rope[1]) is more appropriate IMHO. [1] http://en.wikipedia.org/wiki/Rope_(computer_science) http://en.wikipedia.org/wiki/Rope_(computer_science)
- Dove 15y ago
  That's kind of what I mean. The fact that null-terminated strings can get arbitrarily long doesn't seem like a big advantage. I mean, if you're working with really long strings, you probably want to use something more sophisticated than a character array anyway.

by Dove 15y ago

burgerbrain 15y ago

I mean, a 64k string is plenty for your everyday string needs. No, not for my everyday needs.

jerf 15y ago
But the question here isn't actually "What is the ONE TRUE STRING format that the language permits, all others to be rigidly banned by the compiler?", the question is "What shall the default string be in the core C APIs and functions?" If you still need NULL-terminated strings, you could have chosen them, and if you knew enough to so choose, hopefully you know enough to treat them like the dangerous tools they are. Meanwhile, the core C functions and API and UNIX could have been built around the much safer strings, which wouldn't have been all that hard to upgrade to 4 bytes (or more) later. Or we could have done a UTF-8-like size encoding, or turn the default strings into linked lists if they got large, etc. It would be OK, because raw expanses of memory would still be available to you, it just wouldn't be the default. NULL-terminated strings are the wrong default, even though they should be available to those who really need them.
- burgerbrain 15y ago
  Multiple string schemes is exactly the sort of fragmentation this industry does not need. Citation: C++.
  - tptacek 15y ago
    You mean, basic_string and charstar?
    - copper 15y ago
      Hm, It can be a real problem if you have the joy of working with old C++ code: the initial codebase might have had its own string type, and then some more classes added by long-gone programmers who thought the earlier types were slow, and then newer code added by people who actually use std::string (well, you get the idea). (much to my regret, that is a true story.)

dkersten 15y ago

For those kinds of tasks, a string doesn't seem all that appropriate to me. The BigString (that is, a Rope[1]) is more appropriate IMHO. [1] http://en.wikipedia.org/wiki/Rope_(computer_science) http://en.wikipedia.org/wiki/Rope_(computer_science)

Dove 15y ago
That's kind of what I mean. The fact that null-terminated strings can get arbitrarily long doesn't seem like a big advantage. I mean, if you're working with really long strings, you probably want to use something more sophisticated than a character array anyway.