220 10101 <6838b332-f256-45e7-894b-7cba3593d789@isocpp.org> article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Shouldn't the constexpr variables be treated as static by default? Date: Sun, 30 Mar 2014 21:39:58 -0700 (PDT) Lines: 109 Approved: news@gmane.org Message-ID: <6838b332-f256-45e7-894b-7cba3593d789@isocpp.org> References: <21e34045-b833-4468-a39e-dbf177938012@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_686_12064553.1396240798301" X-Trace: ger.gmane.org 1396240806 12728 80.91.229.3 (31 Mar 2014 04:40:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2014 04:40:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBHXD4OMQKGQEDJVDGAY@isocpp.org Mon Mar 31 06:40:01 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WUU0u-0001XT-SZ for gclcip-std-proposals@m.gmane.org; Mon, 31 Mar 2014 06:40:01 +0200 Original-Received: by mail-ie0-f198.google.com with SMTP id to1sf27696251ieb.5 for ; Sun, 30 Mar 2014 21:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=jStMAGHWnIdnRmFqzOM1Jni+FLY3qAZWGTiEVlzRFg8=; b=WMRlKuC/54Zufq0amux5n4+cKD6MJWPwKOS0XjxLVuDVl7H8TEhCvYvrwkLDx8wQS+ Jz/TDfPRdy69GGzOrj9vvrZHgypamuYRgBtDA7ZGdmgznUgM/yC+XUxsi950SENFwV5p PDuV98/BVbEyDMPgv0UgGTytoaI0Xg9jH13hcCAwIgm4Erz1nfyr4aXbmrJ7N0VOh5Q7 eCtBaSvG5dfhram7aY1VIq4ipJX1LKTBuepTLdt8RrqrLueVEvZc2e2FfL9vdFCTX1LK /MnstnrjLRtIS8wVjGHFqV8h/8BSVCqJONaqdtYcHl5UV3toZ7/ojWsotF3MfE733RF5 gsJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=jStMAGHWnIdnRmFqzOM1Jni+FLY3qAZWGTiEVlzRFg8=; b=daw1tjeUs1ZJlbXu1weks/TeoQdnw9Ai/siVAwAdf9s3S2748dFQLdsyiayE/OPsOZ AITeEJhAsSNi8r92+EDjL+cSlszYEM3DJ+Wg3rAaJrWLh728x1yMb3wjEydkgpHamxgd b0/sMpmizo0niCRPg94CG2JU7NdHQKb/md7irDQ7N+ZtnwE2sU8nJL7zzKwLWixWU/3p 2CSZk+BKK5zNMGR3QrBVEfAK92KkxOdku9H34bmpvScZqpE9ovba8bXrGy1am+qUn+0M X1N9f/DfI6Es4OajqZ9rOywFMUSbgx/8phs6tjcO0e0dLOqHbZwJ+u4fdOUGhx9bozNj 59ng== X-Gm-Message-State: ALoCoQnYZw7Z+cb6qhzq/nz+a5NCkSdqS/Vq2ZV8G+2/G51AIg96mE8X8m9nUJeQgI2KXGaetUa2 X-Received: by 10.42.123.66 with SMTP id q2mr7504077icr.16.1396240799754; Sun, 30 Mar 2014 21:39:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.50.81 with SMTP id r75ls2404418qga.71.gmail; Sun, 30 Mar 2014 21:39:58 -0700 (PDT) X-Received: by 10.140.37.206 with SMTP id r72mr72859qgr.33.1396240798742; Sun, 30 Mar 2014 21:39:58 -0700 (PDT) In-Reply-To: X-Original-Sender: andrewtomazos@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:10101 Archived-At: ------=_Part_686_12064553.1396240798301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer wrote: > > It sounds to me like you're saying that moving x from one part of the=20 > address space to another would constitute a breaking change. Are you real= ly=20 > making that claim? > The feature of interest is whether the three addresses are equal or=20 distinct... =20 > To put it another way, what in the current standard prevents that code=20 > from printing this? > > 0x400714 > 0x400714 > 0x400714 > [intro.object]/6 prevents this: Two objects that are not bit-=EF=AC=81elds may have the same address if one= is a=20 subobject of the other, or if at least one is a base class subobject of=20 zero size and they are of di=EF=AC=80erent types; otherwise, *they shall ha= ve=20 distinct addresses* With automatic storage duration, the three objects must have distinct=20 addresses. The three above are not distinct addresses. And under this proposed change, what would prevent that code from printing= =20 > this? > > 0x7fff125fdad8 > 0x7fff125fdaa8 > 0x7fff125fda78 > With static storage duration, all names x refer to the same object, so all= =20 variables p must be equal. The above three addresses are not equal. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_686_12064553.1396240798301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer= wrote:

It sound= s to me like you're saying that moving x from one part of the address space= to another would constitute a breaking change. Are you really making that = claim?

The feature of interest is whether the three ad= dresses are equal or distinct...
 

To put it another way, what in the current standard prevents= that code from printing this?

0x400714
0x400714
0x400714

 [intro.object]/6 prevents this:

Two objects that are not bit-=EF=AC=81elds may have the s= ame address if one is a subobject of the other, or if at least one is a bas= e class subobject of zero size and they are of di=EF=AC=80erent types; othe= rwise, they shall have distinct addresses

W= ith automatic storage duration, the three objects must have distinct addres= ses.  The three above are not distinct addresses.

=

And under this proposed change, what would prevent that code= from printing this?

0x7fff125fdad8
0x7fff125fdaa8
0x7fff125fda78

With static storage duration, all names= x refer to the same object, so all variables p must be equal.  The ab= ove three addresses are not equal.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_686_12064553.1396240798301-- .