Jean-Marc Lasgouttes wrote: > Le 06/12/2014 10:52, Georg Baum a écrit : >> Jean-Marc Lasgouttes wrote: >> >>> I like it, but I was hoping we could have a drop-in replacement (so that >>> for example clang would still use a real std:string). This would require >>> to get rid of the str(). Isn't it possible to desclare a an operator() >>> to translate transparently to std::string? >> >> I believe it would be possible technically, but do we want that? This >> would mean that people developing with clang or MSVC would break the >> build from time to time, because they would have no possibility to notice >> if the use a std::string member which does not exist in trivstring. > > It would not be useful, since we have to return string const instead of > string const & anyways. Therefore we cannot be completely transparent.
Yes, this is the minimal price to pay, even if the STL implementation provides a usable std::string. > But since we have the .str() thing, I guess that now the gain wrt your > original deep_copy approach is not so important, or am I wrong? Well, in the current version I ditched .str(). The gain is still that you protect the corresponding member variable 100%, also when using it inside the classs without accessor. With deep_copy(), it would still be possible to use it in a non-thread-safe way from inside the class. Georg
