220 16254 article Path: news.gmane.org!not-for-mail From: Markus Grech Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Pointers to members of unknown class Date: Fri, 13 Feb 2015 09:42:17 -0800 (PST) Lines: 187 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/mixed; boundary="----=_Part_2_480592810.1423849337960" X-Trace: ger.gmane.org 1423849343 17532 80.91.229.3 (13 Feb 2015 17:42:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 17:42:23 +0000 (UTC) Cc: dibeas@ieee.org To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC44PYFDYAGRB6XO7CTAKGQEXX65M5A@isocpp.org Fri Feb 13 18:42:23 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YMKFv-0003hq-SU for gclcip-std-proposals@m.gmane.org; Fri, 13 Feb 2015 18:42:20 +0100 Original-Received: by mail-qa0-f69.google.com with SMTP id j7sf44528240qaq.0 for ; Fri, 13 Feb 2015 09:42:19 -0800 (PST) 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=9lmOuXM62RPT9iBezN8IHhln0CuF6vnGthobOCiRZso=; b=a5b6TqcBSjEPFPH92fT5RejX39bCsHTnqQ5up86zYemywyelKziK+OsnQY52Jh4VDE AKrvYhbWYEdmDebfXtQfo0dFawN0Jw0fc5HAcqMZxVon56uZ7dUUvNzATSHiJJU0OvPa K6FtVLtH8OJEbj61A46AiDaNijYeWjsigqsf3vzrnc9BFFrZHDC22qgyNeNuZQoadlnT NB9yqb7B0fhakrMyZ5Eaw32F2cNzEjH0KpYaQUyiAD46Ib9r6eFw1P094H4YB4YJAXxu 2oswI8+c+YUoQwkTswHDQ2pxm1vd7zr7Ayd4c5KAL/zp2+YBGN/j2VDVsNOAuAB9uTvl 93hQ== 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=9lmOuXM62RPT9iBezN8IHhln0CuF6vnGthobOCiRZso=; b=lNpJsetfzAXvxca7eojW/D/nY1YQeh+k1hJbhAh+JnOJPHj6DpkPsQbi0A7P7v/G7S YxhAi9iNbcdw4o214AwqMUKhv1ojKwxWPPDsfzhcvz5eQIedsFEZvMzqD4HjDcvpAYsm iFAJhFlyX5qwBCcVKKHhBZNqHfLyIhL6z7QW9NX+ILpDN6obbEKpq+zIPxk6Ix8cpf0A N959N0Hk2kstjlvNAuhKaMmL5bXOwVVSiinpkXDJ27vajcFmoX6H6rFrahAAzJUQDnTQ QxPgG6TLyLWw57nkXJutRaPSN39QrfiJ74HtLpsYxwrTvV/y/NrI2yrGLL9l1xtXhuF8 siKQ== X-Gm-Message-State: ALoCoQnWMPTykfeY2+ErHZxXkKIcGhKvI3vjUsiwYmebku13qKH2a9S+9DXPL1GiIdIK6TT+SjLB X-Received: by 10.236.26.108 with SMTP id b72mr9683524yha.33.1423849339001; Fri, 13 Feb 2015 09:42:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.84.116 with SMTP id k107ls1352979qgd.91.gmail; Fri, 13 Feb 2015 09:42:18 -0800 (PST) X-Received: by 10.140.93.12 with SMTP id c12mr144219qge.18.1423849338390; Fri, 13 Feb 2015 09:42:18 -0800 (PST) In-Reply-To: X-Original-Sender: markus.grech@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:16254 Archived-At: ------=_Part_2_480592810.1423849337960 Content-Type: multipart/alternative; boundary="----=_Part_3_637361303.1423849337960" ------=_Part_3_637361303.1423849337960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, February 13, 2015 at 4:42:53 PM UTC+1, David Rodr=C3=ADguez Ibea= s=20 wrote: > > >> This requirement - conversion from one MP to another of the same kind= =20 > and back to be well defined - implies that any two MPs of the same kind= =20 > must be of the same size. > > The requirement that you mention is one of 'reinterpret_cast', although= =20 > the casts that you use in the rest of the document are 'static_cast'. =20 > There is an important difference there, since for the case of 'static_cas= t'=20 > you don't need to change anything, it is a semantically correct cast and= =20 > the compiler can (and currently does in the case of VS) narrow/extend the= =20 > value as needed. > I use static_cast in my examples because I don't cast between unrelated=20 MPs. The example is trying to show usage of this new feature. static_cast(static_cast(some PM1)) would result in UB under the= =20 new rules, while reinterpret_cast would give whatever behaviour is decided= =20 on. In the case of static_cast, the PM2 object would be constructed from=20 the bits that happened to be at the location of the PMU when it was created= =20 from a PM1, which could be using an entirely different representation than= =20 PM2. That's the core issue: PMs of different classes need not have the same= =20 representation. =20 > The requirement above is not "fixed" with the proposal, that basically=20 > creates the equivalent of 'void*' for pointer-to-member, but does not=20 > remove the issue (as mentioned in the "open questions"). =20 > It does fix the issue, because you should never have to cast MPs to another= =20 unrelated one in the first place (see above). And with this proposal you=20 don't, you get a better solution, which is a PMU. =20 > One additional concern I have is that currently that the application of= =20 > unary & to qualified-id that refers to a non-static member of a class=20 > yields a type that might not be obvious to the user [I personally would= =20 > like that changed, but could not defend N3772(*) in the committee and hav= e=20 > not found anyone to do it]: > > struct base { int x; }; > struct derived : virtual base { virtual void f(); }; > PMU pmu =3D &derived::x; // PMU according to proposal's syntax > auto pm =3D static_cast(pmu); // undefined behavior > > The problem here is that the expression '&derived::x' is of type 'int=20 > base::*', which is converted to the universal pointer to member 'pmu', th= e=20 > immediate cast to 'int derived::*' is thus not forming a round trip, but= =20 > the equivalent of 'reinterpret_cast(&base::x)' which is= =20 > most probably not going to yield anything sane. > > This is not something newly introduced in this proposal, but the proposal= =20 > might make it worse in the sense that the implicit conversion from the=20 > pointer-to-member to PMU makes it simpler to make that family of mistakes= ,=20 > which currently can only be hit through 'reinterpret_cast'. > I think you misunderstood my example. The expression &derived::x is=20 unchanged, but the implicit conversion is triggered by giving the variable= =20 a PMU type. Thanks to both of you, I now realize the proposal could be way more clear= =20 and I will try to incorporate your feedback. --=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_3_637361303.1423849337960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, February 13, 2015 at 4:42:53 PM UTC+1, = David Rodr=C3=ADguez Ibeas wrote:
>> This requirement - conversion from one MP to another of the same kind and=20 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=20 'reinterpret_cast', although the casts that you use in the rest of the=20 document are 'static_cast'.  There is an important difference there,= =20 since for the case of 'static_cast' you don't need to change anything,=20 it is a semantically correct cast and the compiler can (and currently=20 does in the case of VS) narrow/extend the value as needed.
I use static_cast in my examples because I don't cast between un= related MPs. The example is trying to show usage of this new feature.
st= atic_cast<PM2>(static_cast<PMU>(some PM1)) would result in UB u= nder the new rules, while reinterpret_cast would give whatever behaviour is= decided on. In the case of static_cast, the PM2 object would be constructe= d from the bits that happened to be at the location of the PMU when it was = created from a PM1, which could be using an entirely different representati= on than PM2. That's the core issue: PMs of different classes need not have = the same representation.
 
The requirement above is not "fixed" with the proposal, that basically=20 creates the equivalent of 'void*' for pointer-to-member, but does not=20 remove the issue (as mentioned in the "open questions"). 
It does fix the issue, because you should never have to cast MPs to=20 another unrelated one in the first place (see above). And with this proposa= l you=20 don't, you get a better solution, which is a PMU.
 
One additional concern I have is that currently that the application of=20 unary & to qualified-id that refers to a non-static member of a=20 class yields a type that might not be obvious to the user [I personally=20 would like that changed, but could not defend N3772(*) in the committee=20 and have not found anyone to do it]:

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

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

This is not something newly introduced in this=20 proposal, but the proposal might make it worse in the sense that the=20 implicit conversion from the pointer-to-member to PMU makes it simpler=20 to make that family of mistakes, which currently can only be hit through 'reinterpret_cast'.
I think you=20 misunderstood my example. The expression &derived::x is unchanged,=20 but the implicit conversion is triggered by giving the variable a PMU=20 type.

Thanks to both of you, I now realize the proposal could be way= more clear and I will try to incorporate your feedback.

--

---
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_3_637361303.1423849337960-- ------=_Part_2_480592810.1423849337960-- .