Boost logo

Boost :

From: Chuck Bear (chuck_at_[hidden])
Date: 2007-12-04 08:54:59

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?


-----Original Message-----
From: boost-bounces_at_[hidden] on behalf of Hervé Brönnimann
Sent: Tue 12/4/2007 4:59 AM
To: boost_at_[hidden]
Subject: Re: [boost] Input archive loads seem to corruptsharedcharacterstd::strings

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
     // borland de-allocator fixup
     if(NULL !=
+ s.clear();
      s.resize(size);<char *>(, size); // <== This looks

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