220 17127 <189212bb-bb9c-4c5d-a984-29ae41e32202@isocpp.org> article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: virtual constexpr fields Date: Mon, 23 Mar 2015 14:30:33 -0700 (PDT) Lines: 209 Approved: news@gmane.org Message-ID: <189212bb-bb9c-4c5d-a984-29ae41e32202@isocpp.org> References: <532355906.19321.1426710347371.JavaMail.yahoo@mail.yahoo.com> <04122f67-f4cd-457c-902e-589091f90063@isocpp.org> <2096343.oZu43OOe1O@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5147_276563614.1427146233529" X-Trace: ger.gmane.org 1427146242 21390 80.91.229.3 (23 Mar 2015 21:30:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 21:30:42 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRB6ULYKUAKGQE2O442QA@isocpp.org Mon Mar 23 22:30:37 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ya9vg-0007GV-Cn for gclcip-std-proposals@m.gmane.org; Mon, 23 Mar 2015 22:30:36 +0100 Original-Received: by iejg9 with SMTP id g9sf139748347iej.0 for ; Mon, 23 Mar 2015 14:30:35 -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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=ZJ9eqlUEPj9SZJGXBxAjo6lRbYHXWxFSXqTGDt+OQos=; b=cS0xas+aNJSLMxXrAOHQjOwE0rNovkQhEYFM9oo1xQ3iQlbuwYxOBzSyznaCflX+BA MO8DcPhuCK5JDJoUCy6mJ2IpSgHWUgMGyojDBxmu+0Q7WFpHAJ3lGv+bDvm854aVeXWv FnUiiqYEZJR66mpENPvz9Ior4bmq26tXs4XnG/ROyXvXLBOaZurbbGwk/Em0o+QO+hJS Misw4dX/dI83XVrXxGBY3bAFReCua7hgxxHtkZwershPvWByScFcbVISGQxaog/2UA+N Y2FRLF/M//jb4bC2ImjDQ08V0EndAEIgLymBbeaBqHK5NU0mfg4MI/uwGzmEsFBeAbVd RuCg== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ZJ9eqlUEPj9SZJGXBxAjo6lRbYHXWxFSXqTGDt+OQos=; b=eP8DuSIksMEidGaO9IZpeXBN133YNIRGLeruBr71pfTg7Eysw96b084oy6gwwIPy9w dZCbZCWYm2/VnEG+AwMCS20TgzrXDhznQr7tDki5xg5NqdqTCqA+UCQT5k0UAczm8yju ekVWzgKRBeJ+qe0D5ViU2IDQ0oQyHvbbRs22NgjsI5ik/vRYbSzJRks3VRbsX2joi4gO /R1ZbNnRYD10HMom2AHr2Q/pbCTxrq0HfTwKtarm1uzeJySdCow5zR3UCxn3XYAFDfwt EzcIiNgvxFyTJsyATuyyU+fkhkdoI8sc1Dwfqt95EvX1c8fmQJGVNKPJX4aAKX+gdF1z F9KA== X-Gm-Message-State: ALoCoQk1cqgMm9YMNEaVwKXuR7DpmEhv837HWqbeAKBp44K7eOCKWyKcbVcKf1CeGnSHRrs3OoQ+ X-Received: by 10.182.22.138 with SMTP id d10mr1381610obf.37.1427146235116; Mon, 23 Mar 2015 14:30:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.6.209 with SMTP id f78ls1961195ioi.13.gmail; Mon, 23 Mar 2015 14:30:34 -0700 (PDT) X-Received: by 10.50.56.17 with SMTP id w17mr358644igp.1.1427146234409; Mon, 23 Mar 2015 14:30:34 -0700 (PDT) In-Reply-To: <2096343.oZu43OOe1O@tjmaciei-mobl4> X-Original-Sender: myriachan@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:17127 Archived-At: ------=_Part_5147_276563614.1427146233529 Content-Type: multipart/alternative; boundary="----=_Part_5148_142679684.1427146233529" ------=_Part_5148_142679684.1427146233529 Content-Type: text/plain; charset=UTF-8 I've wanted a "static virtual" concept just for convenience reasons to solve similar problems. The point would just be to avoid having to have a secondary static function. enum class Type : int { SHOE, }; struct Merchandise { virtual Type GetType() const = 0; }; struct Shoe : public Merchandise { static virtual Type GetType() const override { return Type::SHOE; } }; Type type1 = Shoe().GetType(); Type type2 = Shoe::GetType(); assert(type1 == type2); One possible implementation would be to still be a "thiscall" function, whatever that means to the implementation, but ignoring the "this" parameter. Shoe::GetType() could then pass nullptr as this. Another possible implementation is to emit two functions of different mangled names, one static and one virtual. Either implementation would work fine. Rules as I imagine them: 1. Destructors can't be static virtual. 2. static virtual functions cannot reference this. (obvious) 3. The static attribute is not heritable: a non-static virtual function may override a static virtual function. Possible solutions to the function pointer problem: 4a. It is not possible to get a non-member pointer to a static virtual function. --or-- 4b. Ampersand-prefixed member pointer expressions (I don't remember their formal name)--i.e., &Shoe::GetType--would disambiguate member function pointer and non-member function pointer by context, like occurs for overloaded functions. Melissa -- --- 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_5148_142679684.1427146233529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've wanted a "static virtual" concept just for convenienc= e reasons to solve similar problems.  The point would just be to avoid= having to have a secondary static function.

<= code class=3D"prettyprint">
enum class Type : int
{
    SHOE,
};

struct Merchandise
{
&nbs= p;   = virtual Type<= span style=3D"color: #000;" class=3D"styled-by-prettify"> GetType() const =3D = 0;<= span style=3D"color: #000;" class=3D"styled-by-prettify">
};

struct Shoe : pub= lic Merchandise
{
    static virtual Type GetType() const= override { return Type::SHOE; }
};

Type type1 =3D Shoe(= ).GetType<= /span>();<= span style=3D"color: #000;" class=3D"styled-by-prettify">
Type type2 =3D Shoe::GetType();
= assert(type1 = =3D=3D type2);
One possible implementation would be to still be a "thiscall" function, wh= atever that means to the implementation, but ignoring the "this" parameter.  Shoe::GetType() could the= n pass nullptr a= s this.  An= other possible implementation is to emit two functions of different mangled= names, one static and one virtual.  Either implementation would work = fine.

Rules as I imagine them:

1. Destructors can't be static virtual.
2. = static virtual f= unctions cannot reference this.  (obvious)
3. The static attribute is not heritable: a non-static virtual function = may override a static v= irtual function.

Possible solutions to the function pointer p= roblem:
4a. It is not possible to get a non-member pointer to a static virtual function.=
--or--
4b. Ampersand-prefixed member pointer expressions (I don't re= member their formal name)--i.e., &Shoe::GetType--would disambiguate member function poi= nter and non-member function pointer by context, like occurs for overloaded= functions.

Melissa

--

---
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_5148_142679684.1427146233529-- ------=_Part_5147_276563614.1427146233529-- .