1. "Contiguity"
Continuity and c_str() is one of the most important properties of C++ string (that is BTW required by C++0x)
Eliminating c_str() doesn't mean there's no easy way to produce a contiguous NTBS.
Yes, just it can't be really "char const *c_str() CONST" or would require extra stuff like linearization. It would turn away 90% of users.
3. non-uniform-memory-architecture
Give me a break... Who uses NUMA for string processing?!
Anyone running on a multiprocessor system with AMD Opterons or Intel Nehalem or Tukwila processors. You don't always get to choose the kind of architecture your code will run on, and those systems are all NUMA. But even when you do get to choose, some very large problems that would be appropriate to NUMA involve lots of strings.
1. The locality of cache or private processor cache does not makes them "NUMA" 2. In such case it would be even better to have non-shared strings
4. About string builder. Most languages require is as they don't have "reserve" also if you want efficient string builder use std::ostream with nice stream buffer.
There's nothing efficient about std::ostream, no matter what buffer you put on it.
I beg your pardon? It is efficient as all functions are as efficient as memcpy with exceptions of overflow/underflow happens which require some virtual functions calls which are pretty fast as well... Also 99% of issues are just solved with reserve. (and I work with text parsing, combining and processing a lot)
6. Encoding is extrinsic to strings
?!?!?!
All the discussion in started because we need UTF-8 in strings now we are back to the beginning?
This, I believe, is a persistent misunderstanding. IIUC, Dean is only suggesting to avoid giving UTF-8 any special status in the string's interface. He's not arguing against using UTF-8 storage in the implementation.
The entire "buzz" started with the fact that under windows we have problems with string encoding not being UTF-8
This is classic example of how trying to do something "cool" gives us theoretically interesting and cool things that are useless in real world where simple and straight forward things actually work a way better.
That may ultimately turn out to be true, but your reaction here seems so over-the-top and premature as to make that conclusion very unconvincing.
This article written from wrong understanding of real problems - instead of solving a problem it suggests some idea for some cases not looking to the problem in hole. Starting from "std::string is broken" statement... Artyom