220 16361 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Pointers to members of unknown class Date: Tue, 17 Feb 2015 15:33:01 -0800 Lines: 169 Approved: news@gmane.org Message-ID: References: <9b03a820-0ac5-4931-9825-b2fc9ef893f9@isocpp.org> <3195225.rb5WNQZqGk@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3a950a43d7d050f511fa9 X-Trace: ger.gmane.org 1424216153 17337 80.91.229.3 (17 Feb 2015 23:35:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 23:35:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBLM7R6TQKGQEYCS5OPA@isocpp.org Wed Feb 18 00:35:48 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNrgA-0003WC-7i for gclcip-std-proposals@m.gmane.org; Wed, 18 Feb 2015 00:35:46 +0100 Original-Received: by mail-ig0-f200.google.com with SMTP id b16sf261036755igk.3 for ; Tue, 17 Feb 2015 15:35:45 -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:sender:in-reply-to:references:date :message-id:subject:from: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=YgzT+aKD0PowQmJye1qk7VxYfb1HDHm899TQ53Skq6o=; b=buMyESZOK6/u1oghOzGKmNM5mnX5XkMFrDr2orTvnj32YD3URaXP1a8nQMIZV/VaVW uY96dYXz9X9XQrl8i0OqsDuw+SFe9RghGqptJv6HR/ZMwsQ0gFs9jIudTP8t8MUJxa0X fnqMdfI1WWBTkkaJNcQ8p4QgHsKHHrzsF67TKKOFi9AIFJyY19sTDK+gweuEn90wQUSM jme1Hw3fIStfnz5jtsLvctWNArOGEhtGXjg85YAffH/+1b3hurZdOi3V8oUrw1L22rS4 8JyNvFSiSao89+rsEkbSbf4uuE2ggxtUMCe6anBoEAyBjNas2lDywY5mpoxUvwRolDi3 otBw== X-Gm-Message-State: ALoCoQnl+qL51JyflX9eLBa+8B5CNvY2J5sA/2WlCGCfwNtgX7UvrDU5SDUqvEWzFm2Xp2etPiXz X-Received: by 10.43.36.7 with SMTP id sy7mr30828411icb.32.1424215982309; Tue, 17 Feb 2015 15:33:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.107.38 with SMTP id gz6ls1687685igb.35.canary; Tue, 17 Feb 2015 15:33:01 -0800 (PST) X-Received: by 10.107.154.79 with SMTP id c76mr1208582ioe.14.1424215981470; Tue, 17 Feb 2015 15:33:01 -0800 (PST) Original-Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com. [209.85.223.176]) by mx.google.com with ESMTPS id g123si1855665ioe.96.2015.02.17.15.33.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 15:33:01 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 209.85.223.176 as permitted sender) client-ip=209.85.223.176; Original-Received: by iecrd18 with SMTP id rd18so44841753iec.5 for ; Tue, 17 Feb 2015 15:33:01 -0800 (PST) X-Received: by 10.50.142.38 with SMTP id rt6mr30999109igb.17.1424215981176; Tue, 17 Feb 2015 15:33:01 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.50.186.193 with HTTP; Tue, 17 Feb 2015 15:33:01 -0800 (PST) In-Reply-To: <3195225.rb5WNQZqGk@tjmaciei-mobl4> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 209.85.223.176 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:16361 Archived-At: --001a11c3a950a43d7d050f511fa9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 17, 2015 at 11:52 AM, Thiago Macieira wrote: > On Wednesday 18 February 2015 01:41:31 David Krauss wrote: > > Looking at the proposal again, I find the incomplete classes troubling. > > Isn=E2=80=99t it inconsistent to retroactively change the size of a cla= ss=E2=80=99 PTMs > at > > the time it gets completed? Shouldn=E2=80=99t pointers to members of in= complete > > classes be incomplete too? > > I don't know if the standard says the below code is valid or whether it h= as > undefined- or implementation-defined behaviour. It does compile without > warnings > at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when > using the IA-64 C++ ABI. > > struct S; > typedef int S:: *PTM; > typedef void (S:: *PMF)(int); > > void func(S *s, PMF f, PTM v) > { > (s->*f)(s->*v); > } > > I do know that it may not work properly with MSVC because the pointer-to- > member types may change sizes depending on the inheritance diagram of > class in > question. If the above has implementation-defined behaviour, MSVC is > conformant; if the above is legally-valid code, then MSVC ought to fix > their > ABI... > The above is valid code. (I thought it was generally well-known that MSVC's implementation of pointers-to-members is non-conforming by default.) > If MSVC has broken ABI *every* *single* release in the past 15 years, why > hasn't it fixed the above issue, when there is a clear solution works for > everyone and, moreover, is available via compile switch (the /vmg option) > https://msdn.microsoft.com/en-us/library/yad46a6z.aspx > The /vmg option makes pointers-to-members quite large (3-4 pointers) because it gives a "most general" representation for all pointers-to-members. MSVC's "most general" representation supports (as an extension) things that the standard does not require, such as converting a pointer-to-member of a *virtual* base class to a pointer-to-member of a derived class, and thus cannot be as compact as that of the Itanium C++ ABI. MSVC can't simply switch to a strict, standard-conforming, smaller pointer-to-member representation without breaking existing code that uses its extension. I don't know if that's the reason they've not done anything about this, but it seems like a possible explanation. You can *almost* get a small and correct pointer-to-member representation by using the /vmm switch, but their compiler emits spurious errors if you then take the address of a member of a class that uses virtual inheritance. --=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/. --001a11c3a950a43d7d050f511fa9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 11:52 AM, Thiago Macieira <thiago@macieira.org&g= t; wrote:
On Wedn= esday 18 February 2015 01:41:31 David Krauss wrote:
> Looking at the proposal again, I find the incomplete classes troubling= ..
> Isn=E2=80=99t it inconsistent to retroactively change the size of a cl= ass=E2=80=99 PTMs at
> the time it gets completed? Shouldn=E2=80=99t pointers to members of i= ncomplete
> classes be incomplete too?

I don't know if the standard says the below code is valid or whe= ther it has
undefined- or implementation-defined behaviour. It does compile without war= nings
at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when using the IA-64 C++ ABI.

struct S;
typedef int S:: *PTM;
typedef void (S:: *PMF)(int);

void func(S *s, PMF f, PTM v)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (s->*f)(s->*v);
}

I do know that it may not work properly with MSVC because the pointer-to- member types may change sizes depending on the inheritance diagram of class= in
question. If the above has implementation-defined behaviour, MSVC is
conformant; if the above is legally-valid code, then MSVC ought to fix thei= r
ABI...

The above is valid code. (I thou= ght it was generally well-known that MSVC's implementation of pointers-= to-members is non-conforming by default.)

<rant>
If MSVC has broken ABI *every* *single* release in the past 15 years, why hasn't it fixed the above issue, when there is a clear solution works f= or
everyone and, moreover, is available via compile switch (the /vmg option) https://msdn.microsoft.com/en-us/library/yad46a6z.aspx
</rant>

The /vmg option makes pointer= s-to-members quite large (3-4 pointers) because it gives a "most gener= al" representation for all pointers-to-members. MSVC's "most = general" representation supports (as an extension) things that the sta= ndard does not require, such as converting a pointer-to-member of a *virtua= l* base class to a pointer-to-member of a derived class, and thus cannot be= as compact as that of the Itanium C++ ABI. MSVC can't simply switch to= a strict, standard-conforming, smaller pointer-to-member representation wi= thout breaking existing code that uses its extension.

<= div>I don't know if that's the reason they've not done anything= about this, but it seems like a possible explanation. You can *almost* get= a small and correct pointer-to-member representation by using the /vmm swi= tch, but their compiler emits spurious errors if you then take the address = of a member of a class that uses virtual inheritance.

--

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