immutable strings vs std::string

I found most people in this thread do not really understand what immutable_string is. It is not only about the constness. The really power of immutable_string is the performance (even in single thread program) and the memory usage.

Imagine that, if all strings are immutable, and all string are implemented like

class string {
    char* _head ;
    size_t _len ;
} ;

How can we implement a sub-str operation? We don't need to copy any char. All we have to do is assign the _head and the _len. Then the sub-string shares the same memory segment with the source string.

Of course we can not really implement a immutable_string only with the two data members. The real implementation might need a reference-counted(or fly-weighted) memory block. Like this

class immutable_string {
    boost::fly_weight<std::string> _s ;
    char* _head ;
    size_t _len ;
} ;

Both the memory and the performance would be better than the traditional string in most cases, especially when you know what you are doing.

Of course C++ can benefit from immutable string, and it is nice to have one. I have checked the boost::const_string and the fix_str mentioned by Cubbi. Those should be what I am talking about.

My conclusion is that C++ does not require the immutable pattern because it has const semantics.

In Java, if you have a Person class and you return the String name of the person with the getName() method, your only protection is the immutable pattern. If it would not be there you would have to clone() your strings all night and day (as you have to do with data members that are not typical value-objects, but still needs to be protected).

In C++ you have const std::string& getName() const. So you can write SomeFunction(person.getName()) where it is like void SomeFunction(const std::string& subject).

• No copy happened
• If anyone wants to copy he is free to do so
• Technique applies to all data types, not just strings

You're certainly not the only person who though that. In fact, there is const_string library by Maxim Yegorushkin, which seems to have been written with inclusion into boost in mind. And here's a little newer library, fix_str by Roland Pibinger. I'm not sure how tricky would full string interning at run-time be, but most of the advantages are achievable when necessary.

I don't think there's a definitive answer here. It's subjective—if not because personal taste then at least because of the type of code one most often deals with. (Still, a valuable question.)

Immutable strings are great when memory is cheap—this wasn't true when C++ was developed, and it isn't the case on all platforms targeted by C++. (OTOH on more limited platforms C seems much more common than C++, so that argument is weak.)

You can create an immutable string class in C++, and you can make it largely compatible with std::string—but you will still lose when comparing to a built-in string class with dedicated optimizations and language features.

std::string is the best standard string we get, so I wouldn't like to see any messing with it. I use it very rarely, though; std::string has too many drawbacks from my point of view.

const std::string

There you go. A string literal is also immutable, unless you want to get into undefined behavior.

Edit: Of course that's only half the story. A const string variable isn't useful because you can't make it reference a new string. A reference to a const string would do it, except that C++ won't allow you to reassign a reference as in other languages like Python. The closest thing would be a smart pointer to a dynamically allocated string.

Immutable strings are great if, whenever it's necessary to create a new a string, the memory manager will always be able to determine determine the whereabouts of every string reference. On most platforms, language support for such ability could be provided at relatively modest cost, but on platforms without such language support built in it's much harder.

If, for example, one wanted to design a Pascal implementation on x86 that supported immutable strings, it would be necessary for the string allocator to be able to walk the stack to find all string references; the only execution-time cost of that would be requiring a consistent function-call approach [e.g. not using tail calls, and having every non-leaf function maintain a frame pointer]. Each memory area allocated with new would need to have a bit to indicate whether it contained any strings and those that do contain strings would need to have an index to a memory-layout descriptor, but those costs would be pretty slight.

If a GC wasn't table to walk the stack, then it would be necessary to have code use handles rather than pointers, and have code create string handles when local variables come into scope, and destroy the handles when they go out of scope. Much greater overhead.

Qt also uses immutable strings with copy-on-write.
There is some debate about how much performance it really buys you with decent compilers.

constant strings make little sense with value semantics, and sharing isn't one of C++'s greatest strengths...

Would C++ benefit from immutable strings? Probably not much.

An immutable string is not the same as a read-only string. Immutability guarantees that no change to the observable state of the string may occur outside of what your own code can affect, to the point that if you take any code passing std::string by value, you could just replace it with such an immutable string pointer and everything will work (you cannot distinguish passing such a string by value from passing by reference).

C++ guarantees this only when you create a const object right from the beginning ‒ adding const to an existing object does not make it immutable, and you can remove it via const_cast any time without any issues. This basically means that you cannot make a type immutable in C++, only an object:

const std::string str("hello");
// or
const std::string &str = *new const std::string("hello");

There are actually two guarantees at play here ‒ you cannot modify str via const_cast<std::string&>(str) (undefined behaviour when modifying const object), and you cannot modify the character data via const_cast<char*>(str.data()) (undefined behaviour for data() const). You could theoretically get const_cast<std::string&>(str).data(), and modifying that might be fine for a trivial std::string implementation, but the standard std::string might be optimized so that it stores the character data (up to a size) in the object itself, thus you still risk modifying the object.

How do you pass an immutable object around? You can't.

void f(const std::string &str);

This is no longer an immutable object, but a read-only object ‒ you cannot modify it through str, but it can still change at any time.

To have an actually immutable string, you need to encode this in the type system somehow. The best you can do is to wrap it in another object where it is immutable, like const std::tuple<const std::string> &str ‒ there is no tuple variance that would permit getting this reference from a mutable std::tuple<std::string>, and so, when created, the string is already a const object.

Lastly, you also need guarantees about the lifetime of such an object, since even an immutable object can be deleted. That is thankfully not so complicated ‒ std::shared_ptr<const std::tuple<const std::string>> gives you all the guarantees ‒ once you observe its value, it should stay constant forever. This is pretty much the basis of what languages with immutable strings give you.

Now, to reason about the answer, how would C++ benefit from using such a string? Are there any places where read-only strings are stored, without giving you the control over the specific type? There are not that many I could come up with:

• std::exception ‒ constructing it from an error message needs to copy the string to preserve it, but with an immutable string pointer, it could just store that and return in what(). However, you can create your own exception types that do that.
• std::locale ‒ likewise, constructing from a locale name could just store the immutable string inside, without copying. However, locale names are not that frequently used, and are short enough to make small string optimization kick in for most of cases.
• std::messages ‒ get() could be a primary target for immutable strings, as any other "string catalogs" ‒ retrieval could happen relatively often, and the strings are moderately long and constant enough. Nothing stops you from adding a caching layer to this object however.

I encourage you to find more such examples. Indeed, there are many more cases where strings are accepted and processed, or generated and returned, than simply stored.

That being said, the situation in user code is drastically different ‒ once you store user records or configurations, you become more in need of such a type. So while the C++ language itself might not benefit from it, your code definitely would! Such a type needs to:

• Be easily constructible from a string literal without copying, creating an immutable string with permanent lifetime.
• Be move-constructible from std::string, taking ownership of its character data.
• Be constructible without copying from other objects with lifetime management that exhibit immutability, such as std::shared_ptr<std::array<const char, N>> or the aforementioned tuple.
• Be constructible by value from std::string, char iterators and the usual stuff, copying the data to its internal memory.
• Be "unsafe-constructible" without copying from things like std::shared_ptr<std::span<char>>, where immutability is not guaranteed by the type. This option needs to be clearly marked as dangerous, and modifying the underlying data in any way during the lifetime of the result should cause undefined behaviour.
• Interface well with existing std::shared_ptr-based code, preferably be handled as std::shared_ptr itself.
• Allow allocation-less slicing, producing views into its data with the same lifetime.
• Include compatibility with C strings in the form of const char *data() const for retrieval. Note that sliced strings may be missing the '\0' character at the end, and so there needs to be a way to detect this having happened and return std::shared_ptr<const char*> instead (either aliased to the original data, or to a copy thereof with '\0' at the end).

This interplay between std::shared_ptr and std::string makes such a type definitely preferable to be defined by the standard rather than user code, as some situations could be handled much better without unnecessary allocations or indirection, and the immutability guarantee enables important optimizations.

Strings are mutable in Ruby.

$ irb
>> foo="hello"
=> "hello"
>> bar=foo
=> "hello"
>> foo << "world"
=> "helloworld"
>> print bar
helloworld=> nil

• trivially thread safe

I would tend to forget safety arguments. If you want to be thread-safe, lock it, or don't touch it. C++ is not a convenient language, have your own conventions.

• more secure

No. As soon as you have pointer arithmetics and unprotected access to the address space, forget about being secure. Safer against innocently bad coding, yes.

• more memory efficient in most use cases.

Unless you implement CPU-intensive mechanisms, I don't see how.

• cheap substrings (tokenizing and slicing)

That would be one very good point. Could be done by referring to a string with backreferences, where modifications to a string would cause a copy. Tokenizing and slicing become free, mutations become expensive.