Hervé (and others), Yes, our problem happened when the string was the same size (as it is in the reproducing code I submitted a while ago). (I did not test smaller strings. Nor did I look at the implementation. It seems to me that one could construct reasonable implementations of std::string that worked either way, depending on things like how c_str() is optimized.) In your code below, beware the #ifdef'd 'if' above your change. I'm not sure you want what you'd get if the #ifdef is triggered. Then again, I'm having a hard time understanding the original routine in that regard. It seems very strange to ensure that the string is resized only if the data() isn't NULL. Am I just misreading the code, or does this ensure that the null pointer is chased if the string has NULL data() upon entry to the routine? In general I've heard a lot of suggestions about what would be the fastest on different implementations of std::string. Of course it seems like a good idea to go for the fastest "correct" implementation possible. Does there exist a set of programs that could be run on different platforms (hardware, and libraries) for measuring the relative performance of the proposed solutions? Regards, Chuck -----Original Message----- From: boost-bounces@lists.boost.org on behalf of Hervé Brönnimann Sent: Tue 12/4/2007 4:59 AM To: boost@lists.boost.org Subject: Re: [boost] Input archive loads seem to corruptsharedcharacterstd::strings --snip-- In short, I don't think you can avoid the cost of going over your string twice, so I can't see anything better than: text_iarchive_impl<Archive>::load(std::string &s) { std::size_t size; * this->This() >> size; // skip separating space is.get(); // borland de-allocator fixup #if BOOST_WORKAROUND(_RWSTD_VER, BOOST_TESTED_AT(20101)) if(NULL != s.data()) #endif + s.clear(); s.resize(size); is.read(const_cast<char *>(s.data()), size); // <== This looks suspect }