Re: [boost] Input archive loads seem to corrupt sharedcharacterstd::strings

From: Herve Bronnimann (hervebronnimann_at_[hidden])
Date: 2007-12-05 09:39:36

Jens:  I think you just proved once again that there usually are no benefits in going around good ol' standard compliant code.  BTW, I looked up the undefined behavior rules in the C++ standard and it is unclear to me that the const_cast (however buggy) is undefined behavior, if you stick by the rules of 7.1.6.1;  after all the data() pointer does not point to a const object (it points to the member s._M_data in that implementation, which isn't const since s is passed non-const in that scope).  But regardless, the code is buggy with data().

So I tried to follow your advice and eliminate the const_cast.  Comes a simple idea:  just replace s.data() by  &(*s.begin()).  No need for clear() or any other operation, it's standard-compliant and well-defined behavior, etc.  Minimal change, no swap, no unnecessary allocation (I think).   Even strongly exception safe, if string is strongly exception safe, because if resize() or begin() trigger an exception during allocation, s should be unchanged. 

Do you like that?  I do.  I"m cc'ing Robert on this one.
--
Herve Bronnimann
hervebronnimann_at_[hidden]
PS: Speaking of C++ standard and strings and exception, I can't find anywhere that specifies that strings are strongly exception safe.  Vector guarantees it, and it should be easier for strings than for vector since it can only contain PODs, but I truly cannot see the clause in Chapter 21.  Anyone?
 
On Tuesday, December 04, 2007, at 05:12AM, "Jens Seidel" <jensseidel_at_[hidden]> wrote:
>There is only one solution: remove the buggy casting code and replace it
>with a proper one as suggested. Whether the proper one is slower or not
>is unimportant!  [snip] Don't rely on such stuff, rely on the C++ standard!
> 
>Jens
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>