Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-03 12:39:42

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 whatever gets
done in this thread we won't be making lexical_cast threadsafe until you fix

> 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
> 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 to develop it into a full blown proposal?


Boost list run by bdawes at, gregod at, cpdaniel at, john at