41–50 of 58 posts
I don't really understand why you would want this other than to trick yourself into thinking you are writing java. (I already find it really annoying when people port their Javaisms to C++.)
But one of the big feature of C++ is that it lets you write in any languageisms you want! ;)
Earlier quoted context omitted.
The page is down, but: Most languages have immutable strings. Also, I hope you're not suggesting immutability is a Javaism...
Yes, actually, I don't think it's controversial to say that Java did more to popularize immutable strings than any of the languages you're thinking of. And when people get CS degrees completely centered around Java, bring this kind of "feature" and others to C++, they end up churning out what looks a lot like pretend-Java.
Back then when I graduated (1999), at least in Portugal there were lots and lots of languages to use for assignments, during the degree (5 years long).
Earlier quoted context omitted.
I'm toying with implementing O(1) copies by using a reference counted pointer to basic_string instead of storing it by value within the class. It would mean a small memory overhead and another level of indirection, but probably worth doing. Thoughts?
Most implementations are reference counted with copy on write. No point.
I guess I expected the whole point of an immutable string class would be to have O(1) copies. What does this buy you beyond 'const std::string'?
I'm toying with implementing O(1) copies by using a reference counted pointer to basic_string instead of storing it by value within the class. It would mean a small memory overhead and another level of indirection, but probably worth doing. Thoughts?
Earlier quoted context omitted.
Why (are mutable strings insane)?
OK, that comment was too light on substance. The problem with strings being mutable by default is that one has to do a lot of defensive copying to avoid unexpected behavior. Mutable strings do have their place, inside a function that's building up a string, before that string is visible to any other part of the program. But it shouldn't be the default. See also: "The Value of Values" by Rich Hickey ( http://www.infoq…
Earlier quoted context omitted.
That is accurate. The object reference by immutable msg is hello_world which is mutable. If the value of hello_world changes, then the value of msg changes too. In the simple example, it won't happen, but the point is that it could , especially when multi-threaded.
I don't buy it, by calling that function, the caller is saying the value won't change underneath you (because you are being called in multithreaded code). The object itself cannot change itself, though of course there can be mutable members, which tend to be syncronisation mechanisms (mutexes) anyway.
This isn't so much an issue for functions, where the caller is stopped while the callee runs, but it needs to be borne in mind for longer-lived objects that take const references - or, indeed, const pointers - to objects that have longer lifetimes again. (I don't think multithreading need be introduced for this to be an issue.)
There's quite a difference between an object that could change and one that won't, if you're considering caching values across method calls, or setting up the referring object based on the referred object's current state, etc.
Earlier quoted context omitted.
Most implementations are reference counted with copy on write. No point.
libc++ (the Clang project standard C++ library) doesn't use COW for std::string, and I'm pretty sure GNU stdlibc++ will also drop it the next time they have to break ABI. C++11 move semantics and the 'small string optimisation', as it's known, blow away any performance benefit of COW for most sane uses.
Earlier quoted context omitted.
I don't buy it, by calling that function, the caller is saying the value won't change underneath you (because you are being called in multithreaded code). The object itself cannot change itself, though of course there can be mutable members, which tend to be syncronisation mechanisms (mutexes) anyway.
No, the caller is saying that the callee isn't permitted to change the value! That's what const means. No promise is made about the actual object itself. There's no general way to specify that in C++. This isn't so much an issue for functions, where the caller is stopped while the callee runs, but it needs to be borne in mind for longer-lived objects that take const references - or, indeed, const pointers - to object…
Earlier quoted context omitted.
I'm toying with implementing O(1) copies by using a reference counted pointer to basic_string instead of storing it by value within the class. It would mean a small memory overhead and another level of indirection, but probably worth doing. Thoughts?
There's no point. Just make your class movable.