220 16252 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Pointers to members of unknown class Date: Fri, 13 Feb 2015 15:42:51 +0000 Lines: 237 Approved: news@gmane.org Message-ID: References: <9b03a820-0ac5-4931-9825-b2fc9ef893f9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11354faae0e5cf050efa1657 X-Trace: ger.gmane.org 1423842181 14709 80.91.229.3 (13 Feb 2015 15:43:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 15:43:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIIVO6GQULBB7FW7CTAKGQEDACCG5Q@isocpp.org Fri Feb 13 16:42:56 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YMIOM-0000fK-93 for gclcip-std-proposals@m.gmane.org; Fri, 13 Feb 2015 16:42:54 +0100 Original-Received: by mail-ob0-f197.google.com with SMTP id wo20sf114512511obc.0 for ; Fri, 13 Feb 2015 07:42:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=Kp2zk5Hl7GnPxshiEoBYjp40GzaytYVM09o3IgEMIBI=; b=VDvDV5cyXTrDVo8vUJjEWyI2kagjcfQs7kjDZ4gXb5H+PACctmqTx5enbBXhE1kXn7 5u9xtxJfJoN9+HVqVpuNgWBliKFw+PH7jV853sX5lnC5+WW4lwqnFNOd4YS3tMs5hZt6 iin3oNgzrYd9ndydMsNdiHI9CMKoxyQ0WU4HpNj3lDtg7FWfmfmrD8c5UTiLdJtfrDq0 OZEOuIelyrgKl9rlqjMxn05P9iTuA4ZufgSWxknP3c342tsO0MfweRHiqeF97I6rvyvQ lJ3kfgVquuBFig0sMmtfrk0n5zKjxfQYHsPv5+bMnZ4uOSeWZzaRaN9r1LZIiF2xoBmd BoDw== X-Gm-Message-State: ALoCoQkUlmjePKm0GboXMENa+6t497rOw96EeYLM20qYQ4QFbx5aeL59U6rucO4qL2UlIH/iuqvH X-Received: by 10.50.154.41 with SMTP id vl9mr4003582igb.6.1423842172932; Fri, 13 Feb 2015 07:42:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.17.115 with SMTP id 106ls1476290qgc.57.gmail; Fri, 13 Feb 2015 07:42:52 -0800 (PST) X-Received: by 10.170.86.9 with SMTP id d9mr10571899yka.36.1423842172150; Fri, 13 Feb 2015 07:42:52 -0800 (PST) Original-Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com. [209.85.192.52]) by mx.google.com with ESMTPS id m8si3195232qao.65.2015.02.13.07.42.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 07:42:52 -0800 (PST) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 209.85.192.52 as permitted sender) client-ip=209.85.192.52; Original-Received: by mail-qg0-f52.google.com with SMTP id h3so13689805qgf.11 for ; Fri, 13 Feb 2015 07:42:52 -0800 (PST) X-Received: by 10.140.232.149 with SMTP id d143mr2829186qhc.82.1423842171998; Fri, 13 Feb 2015 07:42:51 -0800 (PST) X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 209.85.192.52 as permitted sender) smtp.mail=dribeas@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:16252 Archived-At: --001a11354faae0e5cf050efa1657 Content-Type: text/plain; charset=UTF-8 >> This requirement - conversion from one MP to another of the same kind and back to be well defined - implies that any two MPs of the same kind must be of the same size. The requirement that you mention is one of 'reinterpret_cast', although the casts that you use in the rest of the document are 'static_cast'. There is an important difference there, since for the case of 'static_cast' you don't need to change anything, it is a semantically correct cast and the compiler can (and currently does in the case of VS) narrow/extend the value as needed. The requirement above is not "fixed" with the proposal, that basically creates the equivalent of 'void*' for pointer-to-member, but does not remove the issue (as mentioned in the "open questions"). A different solution would be to introduce a new generic 'void-pointer-to-member' kind of type and change the requirements in 'reinterpret_cast' so that the roundtrip "original-pointer-to-member -> generic-pointer-to-member -> original-pointer-to-member" is guaranteed, without the stricter guarantee of the intermediate step being "any" pointer to member, and possibly leaving that alternative as implementation defined. This could be either a single 'generic-pointer-to-member' or two of them, one for pointers to data members and another for pointer to member functions. I don't think we need 'T void::*' for every possible 'T', a single alternative: 'void void::*' [or 'auto auto::*', although this has a different meaning in the concepts TS, IIRC, but it could also be spelled completely differently as 'std::ptrmbr']. The impact would be that certain programs that are now well defined (in the standard, but would fail in VS implementation) would become "implementation defined", which is kind of fine anyway --they will still work where they worked before and fail where they would currently fail. Should conversions to that generic pointer type be implicit? Not sure. Should 'static_cast' allow the opposite conversion? Not sure either. I don't love the idea of 'static_cast(static_cast(&i))' in the first place, that screams "reinterpret_cast" and I believe it should be typed as such. On the other hand the evolution of the language has moved in the direction of strengthening that conversion sequence 'static_cast(static_cast(&aFloat))' is well defined in C++14 (although uses of the resulting pointer are a violation of the strict aliasing rules, but what address is pointed to is guaranteed). So allowing the conversion through 'static_cast' is just consistent with that behavior. On the question of whether applying a PMU directly should be allowed, I tend to fall on the safe side: I would not allow it. One additional concern I have is that currently that the application of unary & to qualified-id that refers to a non-static member of a class yields a type that might not be obvious to the user [I personally would like that changed, but could not defend N3772(*) in the committee and have not found anyone to do it]: struct base { int x; }; struct derived : virtual base { virtual void f(); }; PMU pmu = &derived::x; // PMU according to proposal's syntax auto pm = static_cast(pmu); // undefined behavior The problem here is that the expression '&derived::x' is of type 'int base::*', which is converted to the universal pointer to member 'pmu', the immediate cast to 'int derived::*' is thus not forming a round trip, but the equivalent of 'reinterpret_cast(&base::x)' which is most probably not going to yield anything sane. This is not something newly introduced in this proposal, but the proposal might make it worse in the sense that the implicit conversion from the pointer-to-member to PMU makes it simpler to make that family of mistakes, which currently can only be hit through 'reinterpret_cast'. David [*] N3772 mistakenly misrepresents the problem with the templates making it look like there is a workaround for the template problem where there isn't. The first example's workaround is illegal: struct A { int i; }; struct B : A {}; template struct example1 {}; example1(&B::i)> x; // error On Fri Feb 13 2015 at 4:38:08 AM Markus Grech wrote: > Hello everyone, > > in the past few days I have started working on a proposal for a new > language feature that I call "pointers to members of unknown class". > I would like some feedback on the proposal as well as the idea itself. > > > https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing > > I have not looked into providing a standard wording yet. > > Markus > > -- > > --- > 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/. > -- --- 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/. --001a11354faae0e5cf050efa1657 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>=C2=A0This requirement - conversion from one MP to= another of the same kind and back to be well defined - implies that any tw= o MPs of the same kind must be of the same size.

The requirement tha= t you mention is one of 'reinterpret_cast', although the casts that= you use in the rest of the document are 'static_cast'.=C2=A0 There= is an important difference there, since for the case of 'static_cast&#= 39; you don't need to change anything, it is a semantically correct cas= t and the compiler can (and currently does in the case of VS) narrow/extend= the value as needed.

The requirement above is not "fixed"= with the proposal, that basically creates the equivalent of 'void*'= ; for pointer-to-member, but does not remove the issue (as mentioned in the= "open questions"). =C2=A0

A different solution would be t= o introduce a new generic 'void-pointer-to-member' kind of type and= change the requirements in 'reinterpret_cast' so that the roundtri= p "original-pointer-to-member -> generic-pointer-to-member -> or= iginal-pointer-to-member" is guaranteed, without the stricter guarante= e of the intermediate step being "any" pointer to member, and pos= sibly leaving that alternative as implementation defined.=C2=A0 This could = be either a single 'generic-pointer-to-member' or two of them, one = for pointers to data members and another for pointer to member functions. I= don't think we need 'T void::*' for every possible 'T'= , a single alternative:
'void void::*' [or 'auto auto::*'= ;, although this has a different meaning in the concepts TS, IIRC, but it c= ould also be spelled completely differently as 'std::ptrmbr'].
<= br>The impact would be that certain programs that are now well defined (in = the standard, but would fail in VS implementation) would become "imple= mentation defined", which is kind of fine anyway --they will still wor= k where they worked before and fail where they would currently fail.
Should conversions to that generic pointer type be implicit? Not sure. Sho= uld 'static_cast' allow the opposite conversion? Not sure either. I= don't love the idea of 'static_cast<int*>(static_cast<voi= d*>(&i))' in the first place, that screams "reinterpret_cas= t" and I believe it should be typed as such. On the other hand the evo= lution of the language has moved in the direction of strengthening that con= version sequence 'static_cast<int*>(static_cast<void*>(&= ;aFloat))' is well defined in C++14 (although uses of the resulting poi= nter are a violation of the strict aliasing rules, but what address is poin= ted to is guaranteed). So allowing the conversion through 'static_cast&= #39; is just consistent with that behavior.

On the question of wheth= er applying a PMU directly should be allowed, I tend to fall on the safe si= de: I would not allow it.

One additional concern I have is that curr= ently that the application of unary & to qualified-id that refers to a = non-static member of a class yields a type that might not be obvious to the= user [I personally would like that changed, but could not defend N3772(*) = in the committee and have not found anyone to do it]:

struct base { = int x; };
struct derived : virtual base { virtual void f(); };
PMU pm= u =3D &derived::x; // PMU according to proposal's syntax
auto pm= =3D static_cast<int derived::*>(pmu); // undefined behavior

T= he problem here is that the expression '&derived::x' is of type= 'int base::*', which is converted to the universal pointer to memb= er 'pmu', the immediate cast to 'int derived::*' is thus no= t forming a round trip, but the equivalent of 'reinterpret_cast<int = derived::*>(&base::x)' which is most probably not going to yield= anything sane.

This is not something newly introduced in this propo= sal, but the proposal might make it worse in the sense that the implicit co= nversion from the pointer-to-member to PMU makes it simpler to make that fa= mily of mistakes, which currently can only be hit through 'reinterpret_= cast'.

=C2=A0 =C2=A0 David

[*] N3772 mistakenly misrepres= ents the problem with the templates making it look like there is a workarou= nd for the template problem where there isn't. The first example's = workaround is illegal:

struct A { int i; };
struct B : A {};
t= emplate <typename T, int T::*MPTR> struct example1 {};
example1<= ;B, static_cast<int B::*>(&B::i)> x; // error


On Fri Feb 13 2015 at 4:38:08 AM Markus Grech <markus.grech@gmail.com> wrote= :
Hello everyone,
in the past few days I have started working on a proposal for = a new language feature that I call "pointers to members of unknown cla= ss".
I would like some feedback on the proposal as well as t= he idea itself.


I have not looked into providing a standard wording yet.

Markus

--

---
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-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/gro= up/std-proposals/.

--

---
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>.
--001a11354faae0e5cf050efa1657-- .