220 17097 <349e79f9-9f3d-4318-b328-c162be011f79@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: virtual constexpr fields Date: Wed, 18 Mar 2015 18:30:17 -0700 (PDT) Lines: 87 Approved: news@gmane.org Message-ID: <349e79f9-9f3d-4318-b328-c162be011f79@isocpp.org> References: <532355906.19321.1426710347371.JavaMail.yahoo@mail.yahoo.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7403_1848766964.1426728617273" X-Trace: ger.gmane.org 1426728621 2758 80.91.229.3 (19 Mar 2015 01:30:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Mar 2015 01:30:21 +0000 (UTC) Cc: c++std-ext@accu.org, ehsan@mozilla.com, botond_ballo@yahoo.ca, botond_ballo@yahoo.ca To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKWNVCUAKGQEPUHX47Q@isocpp.org Thu Mar 19 02:30:20 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YYPHv-0005t5-W1 for gclcip-std-proposals@m.gmane.org; Thu, 19 Mar 2015 02:30:20 +0100 Original-Received: by ieczq1 with SMTP id zq1sf105540206iec.2 for ; Wed, 18 Mar 2015 18:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KN0WSYRG1MUyd09pX0Ui0iVxWAHZaW2RBNlSqmkk+dg=; b=U5Bh9pDyRhhJa/oIcPLNogJ72zFsQ8UeVstSJ/pf2x2jIs1E18JDA6uDKzZW5QO7Wt 2hCwvg1CYXdV6Z0kQFeOnf0Wmx7mpmPxRGH4qMSG8iQ4dCZhMxk0jG0Ek0NdxTdztFXX C+7k8c67do7xb9OECjxLGaUhNWjEDtO1AmAyAojhJ/xxfEO7Ly3JBYGDCkIPv6kZ+916 w0imUN4aqS4lx6qRfwlY0sfs6BwjGyTbOMjyvD7w3KKaevnRqmOhcRWLKmsPXyzKL3gf 5WaotTBcwvKXdnLoszsK8YT8a6nbk237UgJITp3usSOjqiGsrv6HM896jsJAtqCf2+/l b7ZQ== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=KN0WSYRG1MUyd09pX0Ui0iVxWAHZaW2RBNlSqmkk+dg=; b=DGsKWYIiziaWry0hs5hLPEgB6lzW1V08O2lRriuHmu3+uaqGVyUYVaxRTxzKs7kG3Z BnAfdCPvhUrxGBntXEuENlIS/DDUqg2PWLaZKFp/DeaWGjeBMqiFkv1BFR43BRmNJzhP l5izvHk8Ki3KFqfWzn20klGZNWaix9gP7MuoMQDOAPAxZcDDyOTm4vlvzgiyws8gyNWz UrrfpEKynVnInOJ05uFCZ6elkhBzpW4is809oyEmemvYwrblussvILrdxjnUyLMknZd8 r9gQa8kvmBXaRlp2jpTGUVfakszA0iM0Bm4G8C20PnT3k6d+039h9acjA0tTsFKNYrOo n8YQ== X-Gm-Message-State: ALoCoQkkdRtNX/EVebeQJ50u3pFGQu6bGTWq9GPLsotnBbiB2/W/LAj0BedHB5V356sxHialGWGW X-Received: by 10.182.114.168 with SMTP id jh8mr59275317obb.28.1426728618707; Wed, 18 Mar 2015 18:30:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.94.131 with SMTP id g3ls889305qge.28.gmail; Wed, 18 Mar 2015 18:30:18 -0700 (PDT) X-Received: by 10.140.108.182 with SMTP id j51mr1193753qgf.24.1426728618006; Wed, 18 Mar 2015 18:30:18 -0700 (PDT) In-Reply-To: <532355906.19321.1426710347371.JavaMail.yahoo@mail.yahoo.com> X-Original-Sender: jmckesson@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:17097 Archived-At: ------=_Part_7403_1848766964.1426728617273 Content-Type: multipart/alternative; boundary="----=_Part_7404_508345137.1426728617273" ------=_Part_7404_508345137.1426728617273 Content-Type: text/plain; charset=UTF-8 Setting aside the bikeshed issue of what words to use to declare it,we first need to define what exactly it is. It's also important to remember that "vtables" don't exist. They're an implementation detail; no compiler is required to use them to make virtual functions/derived classes work. So, you seem to be talking about an object who's storage is directly associated to a type. But, unlike static data members, every type derived from it will have *separate* storage. So "static" is the wrong word. You want these values to be immutable. Once created, their value cannot be changed (and const-casting your way around it yields undefined behavior). So they're like a const variable. While the object value is associated with the type, you want to access them as though they were a member of an instance of that type. And more to the point, you want the value returned to be the value fetched from the object associated with the object's dynamic type. Since a dynamic type is by definition a runtime fetch, it is certainly not "constexpr". Each class needs to initialize this value with its own parameters. But this doesn't happen at construction time; it happens somewhere else. Possibly before the execution of main(). Which means that it's like a static in terms of initialization and destruction. I don't know. This is a whole lot of complexity just to do cheaper RTTI. Wouldn't it make more sense to just add cheaper RTTI to C++? -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_7404_508345137.1426728617273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Setting aside the bikeshed issue of what words to use to d= eclare it,we first need to define what exactly it is. It's also important t= o remember that "vtables" don't exist. They're an implementation detail; no= compiler is required to use them to make virtual functions/derived classes= work.

So, you seem to be talking about an object who's stora= ge is directly associated to a type. But, unlike static data members, every= type derived from it will have separate storage. So "static" is the= wrong word.

You want these values to be immutable. Once created, th= eir value cannot be changed (and const-casting your way around it yields un= defined behavior). So they're like a const variable.

While the objec= t value is associated with the type, you want to access them as though the= y were a member of an instance of that type. And more to the point, you wan= t the value returned to be the value fetched from the object associated wit= h the object's dynamic type. Since a dynamic type is by definition a runtim= e fetch, it is certainly not "constexpr".

Each class needs to initia= lize this value with its own parameters. But this doesn't happen at constru= ction time; it happens somewhere else. Possibly before the execution of mai= n(). Which means that it's like a static in terms of initialization and des= truction.

I don't know. This is a whole lot of complexity just to do= cheaper RTTI. Wouldn't it make more sense to just add cheaper RTTI to C++?=

--

---
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_7404_508345137.1426728617273-- ------=_Part_7403_1848766964.1426728617273-- .