Return-Path: 
 <dev-return-7056-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 21818 invoked from network); 17 Mar 2008 15:22:28 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Mar 2008 15:22:28 -0000
Received: (qmail 92552 invoked by uid 500); 17 Mar 2008 15:22:26 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 92484 invoked by uid 500); 17 Mar 2008 15:22:26 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 92475 invoked by uid 99); 17 Mar 2008 15:22:26 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2008 08:22:26 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of Farid_Zaripov@epam.com
 designates 217.21.63.3 as permitted sender)
Received: from [217.21.63.3] (HELO EPMSA009.epam.com) (217.21.63.3)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2008 15:21:45 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: svn commit: r635439 - /stdcxx/trunk/include/string.cc
Date: Mon, 17 Mar 2008 17:21:54 +0200
Message-ID: <7BDB2168BEAEF14C98F1901FD2DE643801CE33C6@epmsa009.minsk.epam.com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7D3@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: svn commit: r635439 - /stdcxx/trunk/include/string.cc
Thread-Index: AciCcx5DYB0tGFhxQD+KgZU4W9y+gQAXUdcgAVwbqSA=
References: <20080310055240.54E151A9832@eris.apache.org>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7D3@exchmail01.Blue.Roguewave.Com>
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]=20
> Sent: Monday, March 10, 2008 8:36 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r635439 - /stdcxx/trunk/include/string.cc
>=20
> Is this actually safe, and does it actually do what you want? If
> _InputIter::operator* returns a rvalue and you static_cast=20
> that to a const_reference, you will get the address of the=20
> temporary. That address can't reliably be used to to test=20
> that `__first2' is inside `__s' or not, so the bug that you=20
> 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=20
> at all, and if it is a class type, you _should_ be able to=20
> use the result of
> operator->(), but that isn't really safe because it could=20
> return a proxy
> for the actual pointer. I think you could use SFINAE and=20
> traits to detect that the return type of operator->() is a=20
> pointer type if we really wanted to, and then just make a=20
> 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/stdcxx-dev@incubator.apache.org/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.