> -----Original Message----- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2008 8:36 PM > To: [email protected] > Subject: RE: svn commit: r635439 - /stdcxx/trunk/include/string.cc > > Is this actually safe, and does it actually do what you want? If > _InputIter::operator* returns a rvalue and you static_cast > that to a const_reference, you will get the address of the > temporary. That address can't reliably be used to to test > that `__first2' is inside `__s' or not, so the bug that you > are trying to eliminate here will still exist for iterators of this type. Yes, it was what I want. Actually I don't think we need detect the self reference for all posible iterators, that could be passed in string methods. For example the STLport checking the only if _InputIterator type is string::iterator (which is equal to char_type*). I think that checking the iterator and reverse_iterator<iterator> types is enough. What do you think?
> If _InputIter is a pointer type, you should not need a cast > at all, and if it is a class type, you _should_ be able to > use the result of > operator->(), but that isn't really safe because it could > return a proxy > for the actual pointer. I think you could use SFINAE and > traits to detect that the return type of operator->() is a > pointer type if we really wanted to, and then just make a > copy if it isn't. Yes, I agree that using the type traits is more suitable solutuion. I'm not used the type traits in this patch because as Martin said in http://www.mail-archive.com/[EMAIL PROTECTED]/msg05705.htm l that the changes which are using the type traits should be holded until 4.3 release. Another option is adding the overloads for assign(), replace(), insert() methods, but this is not a binary compatible change. Farid.
