Boost logo

Boost :

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

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; 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 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:
> _______________________________________________
> Unsubscribe & other changes:

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