220 17088 article Path: news.gmane.org!not-for-mail From: Cassio Neri Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [c++std-ext-16626] Re: virtual constexpr fields Date: Wed, 18 Mar 2015 22:03:47 +0000 Lines: 393 Approved: news@gmane.org Message-ID: References: <532355906.19321.1426710347371.JavaMail.yahoo@mail.yahoo.com> <11B5438424E807459A28BD01C92339BA759E907C@XMB122CNC.rim.net> <5509F174.7000303@stroustrup.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d044289e8f7688d0511974192 X-Trace: ger.gmane.org 1426716236 7034 80.91.229.3 (18 Mar 2015 22:03:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Mar 2015 22:03:56 +0000 (UTC) Cc: Tony Van Eerd , "std-proposals@isocpp.org" To: c++std-ext@accu.org Original-X-From: std-proposals+bncBDEYBBEU2UGBBRHMU6UAKGQEQPDTYZY@isocpp.org Wed Mar 18 23:03:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f198.google.com ([74.125.82.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YYM45-0000ER-R0 for gclcip-std-proposals@m.gmane.org; Wed, 18 Mar 2015 23:03:49 +0100 Original-Received: by wesk11 with SMTP id k11sf4833963wes.3 for ; Wed, 18 Mar 2015 15:03:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=BX7Z4Ie1WoekR0tlf3HN3Xk8DRaE+2KCC1tH1oCOF9c=; b=QLdQUEwBr52hbbLE3d4N7L8zvK+sDZC58XYbPc4ddynDCWK5GCFeibZWsj3kWo0cK1 NB2FHeMVUukefFNDf+FKV23WQrbHl4CWj8NfhQxrA4fGWLe7UMJW5Pp6qCDqdoS1UTYv qbNvTS0lO5oaNvB75sJbYD/IJy7HRlMDKP1glowEoDz07Y81YV/5HyPr3ON2W2jSZFeQ Jofv4ISSKTzdl0cEG2nLZVV5ywhYXXiAREVna6BQFp6TBBxhkvM4+seFJT9ghohMoiwj q4y5kZJ50NeFSjL2AUgPSERFQNmP2jNog4czD+dDnJNu1z4/PXWq17aDwbkQDJqMy4FN xNPw== X-Gm-Message-State: ALoCoQkyF+6S/Mcx0gVOOKNWdxE8y0+MHPrGoEUiEdUq1fdjHdbAApmIe1yx6hAaEY/V5udsgVfM X-Received: by 10.180.211.199 with SMTP id ne7mr1171260wic.5.1426716229265; Wed, 18 Mar 2015 15:03:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.87.233 with SMTP id bb9ls432770wib.29.gmail; Wed, 18 Mar 2015 15:03:48 -0700 (PDT) X-Received: by 10.180.76.4 with SMTP id g4mr10668468wiw.43.1426716228245; Wed, 18 Mar 2015 15:03:48 -0700 (PDT) Original-Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com. [2a00:1450:400c:c00::22e]) by mx.google.com with ESMTPS id it3si5949213wid.46.2015.03.18.15.03.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 15:03:48 -0700 (PDT) Received-SPF: pass (google.com: domain of cassio.neri@gmail.com designates 2a00:1450:400c:c00::22e as permitted sender) client-ip=2a00:1450:400c:c00::22e; Original-Received: by wgdm6 with SMTP id m6so46789412wgd.2 for ; Wed, 18 Mar 2015 15:03:48 -0700 (PDT) X-Received: by 10.180.80.199 with SMTP id t7mr11038800wix.52.1426716228018; Wed, 18 Mar 2015 15:03:48 -0700 (PDT) Original-Received: by 10.27.91.2 with HTTP; Wed, 18 Mar 2015 15:03:47 -0700 (PDT) Original-Received: by 10.27.91.2 with HTTP; Wed, 18 Mar 2015 15:03:47 -0700 (PDT) In-Reply-To: <5509F174.7000303@stroustrup.com> X-Original-Sender: cassio.neri@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of cassio.neri@gmail.com designates 2a00:1450:400c:c00::22e as permitted sender) smtp.mail=cassio.neri@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:17088 Archived-At: --f46d044289e8f7688d0511974192 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See https://groups.google.com/a/isocpp.org/forum/?nomobile=3Dtrue#!searchin/std= -proposals/virtual$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ If the link doesn't work search for "virtual data members" in future proposals. Cassio. On 18 Mar 2015 21:46, "Bjarne Stroustrup" wrote: > (1) yes it should be immutable > (2) I described something like that in D&E (and maybe even in the ARM) > (3) what's the important use case? > > On 3/18/2015 4:57 PM, Ehsan Akhgari wrote: > > On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd > wrote: > >> I would say it needs to be constexpr or static =E2=80=93 at least for i= t to be >> stored in the vtable. >> >> (ie assuming the vtable is shared by all instances of the class means >> that the value is shared by all instances of the class) >> > > Yes, exactly. Note that from a pragmatic standpoint, it's probably > important for compilers to be able to store the vtable in read-only memor= y > in order to protect against security attacks attempting to overwrite vtab= le > entries at runtime. > > >> >> >> *From:* Gabriel Dos Reis [mailto:gdr@microsoft.com] >> *Sent:* Wednesday, March 18, 2015 4:42 PM >> *To:* 'std-proposals@isocpp.org'; C++std-ext; ehsan@mozilla.com >> *Subject:* [c++std-ext-16622] Re: [std-proposals] virtual constexpr >> fields >> >> >> >> Does the non-static data member need to be constexpr if it is virtual? >> Why? >> >> >> >> -- Gaby >> >> >> >> *From:* 'Botond Ballo' via ISO C++ Standard - Future Proposals [ >> mailto:std-proposals@isocpp.org ] >> *Sent:* Wednesday, March 18, 2015 1:26 PM >> *To:* C++std-ext; ehsan@mozilla.com; std-proposals@isocpp.org >> *Subject:* [std-proposals] virtual constexpr fields >> >> >> >> There are cases where you would like to associate constants with a given >> type. Here is how you can currently do it in C++: >> >> struct Merchandise { >> virtual int price() { return 0; } >> }; >> >> struct Shoe : Merchandise { >> virtual int price() { return 10; >> } >> >> If you could do it this way instead: >> >> struct Merchandise { >> virtual constexpr int price =3D 0; >> }; >> >> struct Shoe : Merchandise { >> virtual constexpr int price =3D 10; >> } >> >> then the compiler could store the constant value directly in the vtable. >> This would eliminate the double indirection involved in dereferencing a >> function vtable entry, the cost of running that function at runtime, and >> the code size of the function in the compiled binary. >> >> Virtual fields would be limited to being constexpr, so that the value to >> be placed in the vtable, like other values in the vtable, can be determi= ned >> at compile time. >> >> Has this, or something similar, ever been proposed? Is there any interes= t >> in it? >> >> -- Botond and Ehsan >> >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email 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-proposals/. >> > > > > -- > Ehsan > > > --=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/. --f46d044289e8f7688d0511974192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

See

https://groups.google.com/a/isocpp.org/forum/?no= mobile=3Dtrue#!searchin/std-proposals/virtual$20data$20members/std-proposal= s/Z1QG_3Mrn0Y/lzrwNxDeKUQJ

If the link doesn't work search for "virtual data m= embers" in future proposals.

Cassio.

On 18 Mar 2015 21:46, "Bjarne Stroustrup&qu= ot; <bjarne@stroustrup.com&= gt; wrote:
=20 =20 =20
(1) yes it should be immutable
(2) I described something like that in D&E (and maybe even in the ARM)
(3) what's the important use case?

On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvaneerd@blackberry.com> wrote:

I would say it needs to be constexpr or static =E2=80= =93 at least for it to be stored in the vtable.

(ie assuming the vtable is shared by all instances of the class means that the value is shared by all instances of the class)


Yes, exactly.=C2=A0 Note that from a pragmatic standpoint, it's probably important for compilers to be able to store the vtable in read-only memory in order to protect against security attacks attempting to overwrite vtable entries at runtime.
=C2=A0

=

=C2=A0<= /span>

From:<= /b> Gabriel Dos Reis [mailto:gdr@microsoft.com]
Sent: Wednesday, March 18, 2015 4:42 PM
To: 'std-proposals@isocpp.org'; C++std-ext; ehsan@mozilla.com
Subject: [c++std-ext-16622] Re: [std-proposals] virtual constexpr fields=

=C2=A0

D= oes the non-static data member need to be constexpr if it is virtual?=C2=A0 Why?

= =C2=A0

-= - Gaby

= =C2=A0

From: 'Botond Ballo' via ISO C++ Standard= - Future Proposals [mailto:std-proposals@isocpp.org]
Sent: Wednesday, March 18, 2015 1:26 PM
To: C++std-ext; ehsan@mozilla.com; std-proposals@isocpp.org
Subject: [std-proposals] virtual constexpr fields

=C2=A0

There are cases where you would like to associate constants with a given type. Here is how you can currently do it in C++:

struct Merchandise {
=C2=A0=C2=A0=C2=A0 virtual int price() { re= turn 0; }
};

struct Shoe : Merchandise {
=C2=A0=C2=A0=C2=A0 virtual int price() { re= turn 10;
}

If you could do it this way instead:

struct Merchandise {
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr= ice =3D 0;
};

struct Shoe : Merchandise {
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr= ice =3D 10;
}

then the compiler could store the constant value directly in the vtable. This would eliminate the double indirection involved in dereferencing a function vtable entry, the cost of running that function at runtime, and the code size of the function in the compiled binary.

Virtual fields would be limited to being constexpr, so that the value to be placed in the vtable, like other values in the vtable, can be determined at compile time.

Has this, or something similar, ever been proposed? Is there any interest in it?

-- Botond and Ehsan

=C2=A0

--

---
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org<= /a>.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.




--
Ehsan

--

---
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>.
--f46d044289e8f7688d0511974192-- .