Return-Path: 
 <stdcxx-dev-return-5735-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 99520 invoked from network); 22 Oct 2007 18:37:26 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 22 Oct 2007 18:37:26 -0000
Received: (qmail 72237 invoked by uid 500); 22 Oct 2007 18:37:14 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 72227 invoked by uid 500); 22 Oct 2007 18:37:14 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 72216 invoked by uid 99); 22 Oct 2007 18:37:14 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Oct 2007 11:37:14 -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: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Oct 2007 18:37:16 +0000
Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com
 [10.22.129.22])
	by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l9MIaE3l007742
	for <stdcxx-dev@incubator.apache.org>; Mon, 22 Oct 2007 18:36:14 GMT
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: r587164 -
 /incubator/stdcxx/branches/4.2.x/include/vector.cc
Date: Mon, 22 Oct 2007 12:37:37 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA705@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: svn commit: r587164 -
 /incubator/stdcxx/branches/4.2.x/include/vector.cc
Thread-Index: AcgU0Jpl3pMBL79hRdeem783yedIPwAAdlUg
References: <20071022172300.B4F7E1A9838@eris.apache.org>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <stdcxx-dev@incubator.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org


Farid,

It seems that this change would cause some potentially serious problems
in two different cases.

  1. _TypeT is a UDT with an implementation of operator& that returns
something that isn't convertible to a pointer type. [compile error]
  2. _TypeT is a UDT with an implementation of opreator& that returns
something convertible to pointer, but the returned value is not the
address of the object. [runtime error]

I see no reason that either of these cases would not be legal. I think
you should be using the allocator_type::address() to get the physical
address of a given object.

Here is a simple testcase that illustrates the compile failure that was
introduced with this change.

  #include <vector>      // for vector

  struct S
  {
      void operator& () const {};
  };

  int main ()
  {
      std::vector<S> v;
      v.insert (v.begin (), S ());

      return 0;
  }

Travis