Corrado Zoccolo wrote:
Hello, It just occurred to me that the thread safety problems with std::string are caused by the fact that the library is trying to decode the user intention from what methods he calls, instead of letting him declare it, and check at compile time that he is complying with the declared intention.
This may be the resulting reason, but the primary reason is that that the C++ std lib isn't designed to be threadsafe. Getting back to lexical cast for a moment, as I think I said somewhere in the thread, string is not your only problem std::stringstream is your not thread safe either....so whatever gets done in this thread we won't be making lexical_cast threadsafe until you fix iostreams...
I'm thinking to a solution in which the user has the choice of an immutable string, that behaves much like a ref counted "const char *" (or a String in java), and a mutable string as Java's StringBuilder. Something similar has been proposed also during the discussion on SuperString, and now it founds a further motivation for thread safety reasons.
For performance reasons (that is involved here, otherwise a basic deep copy implementation would suffice to solve all problems), I think a third usage type can be added: temporary strings, that are used to mimic move semantics, until they are introduced into the language.
I guess. I have to say that after doing some pretty heavy string coding in Java I personally don't like having to think about the distinction between the 'builder' and the 'string'. Perhaps I'm just brainwashed to the C++ way, but it's nice to just write std::string and not worry about if the code I write tomorrow will be modifying it. Having to mess with another type is clunky and requires refactoring previous thinking. But, I do understand the reasons and respect that some programmers prefer this approach. So far the performance tests I wrote during the super_string discussion don't give a compelling edge to boost const_string -- it could just be a problem with the implementation, but at the moment it mostly loses to std::string.
Now some sketched code, to explain better what I mean (I leaved out a lot of details as templated charT, charTraits and allocator):
<snip details>
Maybe a usage example of this code would be useful in understanding? I guess the point is that since there is no mutating operator[] on imm_string it means that all query operations are threadsafe?
This scheme addresses the performance problems noted in http://www.sgi.com/tech/stl/string_discussion.html for reference counted strings with unshareable state (like the g++ implementation), because now shareable/unshareable state is assigned by the user at compile time, and can be explicitly changed. In this way the user will know what to expect from the performance point of view, and the semantics will be (to my eyes) more clear.
This seems like a reasonable approach for those that want to go the immutable route....care to develop it into a full blown proposal? Jeff