On 12/04/2014 03:59 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Another possibility could be to define a trivial_string class only for
storage in our objects. This class would not be able to do anything
besides reading and setting, but would be transparently compatible with
std::string. It seems to be that we could be able to just change the .h
files and be done with it.
After further thinking about it and doing some experiments I think this is
indeed the best compromise. While doing that I found out about a GNU
extension <ext/vstring.h> (which can be used with either a refcounting base
class or with a non-refcounting one). I was hoping to use std::string where
it it safe, and __gnu_cxx:__vstring else, but this did not really work (the
fact that it is a GNU extension would not be a problem, since the bug we are
trying to fix is only in GNU STL).
Attached you can find the implementation of such a trivstring class, and as
an example the work which needs to be done to make the Language class
threadsafe without requiring locking for all const accesses (except the
Encoding pointer, the Encoding class would need a similar treatment).
I would propose to put this in master (and extend it to other classes where
needed) and to use the deep_copy() helper in very few selected places in
branch. OK?
That sounds reasonable to me. I guess we can hope that the gcc folks
will fix this problem at
some point before it bites more people, and we can just proceed
step-by-step for the time being.
Richard
