Excuse my ignorance, but can someone explain to me why people are so keen on immutable strings? Aren't they basically the same as 'shared_ptr<const std::string>'? I follow these discussions, and I must admit that I already use std::string in my projects with utf8 encoding assumed by default. What matters for me is the lack of a "standard" way to manipulate those strings. I.e.: 1) Convert them to and from other APIs' encoding: SetWindowTextW(to_utf16(my_string)); 2) Iterate through the codepoints, characters, words etc.. like this: for(char32_t cp : codepoints(my_string)) ...; The original proposal (in the other thread) was to use the type of the string to ensure at compile time that the above code is valid. I understand that it is needed in the current world where not everybody uses utf8. It's fine for me. But why On Fri, Jan 21, 2011 at 13:25, Matus Chochlik <chochlik@gmail.com> wrote:
create a class called boost::string that will have all the properties that a string handling class in 2011+ A.D. should have, basically what std::string should have been.
? What are those properties? Isn't std::string *is* what it should have been? Do you mean that you want to put there in any possible algorithm you can imagine? IMO std::string is just a container of bytes with two useful convenience methods (c_str() and substr()) and a utf8 encoding that had to be assumed by default but unfortunately isn't. Everything else should be generic algorithms that work with sequences of characters in some encoding. So, maybe it's better to focus on designing something like boost::iterator_range with an encoding associated with it and algorithms that work with these ranges? -- Yakov