|
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?
Regards,
Chuck
-----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
--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
}
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk