Re: [boost] Input archive loads seem tocorrupt sharedcharacterstd::strings

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-12-05 11:04:01

I've been reading the posts on this subject with interest.  I don't have
strong position myself.  I do believe that some extra effort and/or
risk is justified to get best performance.  I'm leaving for you guys
to do battle over the various alternatives. I strongly believe
in const correctness and believe that things are "const" for a reason
so I'm not enamored with a const_cast of any kind.  I would
much prefer a "guarenteed correct" solution if its close to best
efficiency.

Hence I like the current suggestion.  But does't it presume
that s.begin() points to a real array which would be an implemenation
feature?.  That is, do I know that a standard conforming string
is actually an array of adjacent characters?

Robert Ramey

Herve Bronnimann wrote:
> 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.
>
> 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
>>
>>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost