> All the listed weaknesses also have benefits. For instance it is easy to get a substring without need to copy.

To make substring in some other languages, you need to store pointer to beginning of the substring and length of substring.

To make substring in C, you need to store pointer to beginning of the substring and put '\0' into original string.

> To make substring in some other languages, you need to store pointer to beginning of the substring and length of substring.

Plus a pointer to the beginning, plus a reference counter as the user expects it to manage lifetime. In C this is the user's job. Where they know the life time is guaranteed they can optimize.

I coded in C for over a decade. Never did I need a reference counter.

No, you store offset + length.

You can't use any of the stdlib string functions if you don't have that \0 at the end though, right?

Is there any function you would miss? Of those, which one couldn't you recreate in 5 straightforward lines of code?

O(N) is not the same as O(1).

That substring won't remain valid without copying it.

> That substring won't remain valid without copying it.

Unless it's not modified? And unless, when modified, that shouldn't be its new value?

C Strings (nul-terminated) are the right approach for static storage of small static strings (like strings literals in the source code) since they have low overhead, and "substrings" aren't second-class citizens.

For dynamically allocated strings that won't be modified after creation, the right approach is using a large memory chunk that is shared between many such strings, plus two indices for offset / length (or just offset if it's text that can be terminated with a sentinel).

Having a short string of about 10 characters allocated as a dynamic object in its own allocation is wasteful. Slow to allocate and has about 2x to 3x overhead. This approach isn't good for applications that store a large amount of data.

> O(N) is not the same as O(1).

Don't call strlen() in situations where the strings are large and you need to know the length ahead of time, and running time is paramount. Instead, store the length.

The typical micro-optimization while typing without any profiler feedback, just gut feeling, as prevalent across the community.

You don't need profiler feedback for these things, just back-of-the-envelope calculations. How much data you would like to store and process is not something a profiler can answer for you.

I can tell you that in one of my programs, the difference between garbage collected strings and optimized ones (actually, strings converted into unique integer handles immediately) for one of my projects (SAT solver in Java), handling a few million variables, was something like a second until completion vs a couple of minutes before the garbage collector finally dies due to lack of oxygen, losing all data computed up to that point.