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@users.sf.net> 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