220 16350 <3195225.rb5WNQZqGk@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Pointers to members of unknown class Date: Tue, 17 Feb 2015 11:52:46 -0800 Lines: 59 Approved: news@gmane.org Message-ID: <3195225.rb5WNQZqGk@tjmaciei-mobl4> 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424202788 21669 80.91.229.3 (17 Feb 2015 19:53:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 19:53:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBEVYR2TQKGQEW4UQFVI@isocpp.org Tue Feb 17 20:52:57 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f200.google.com ([209.85.217.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNoCR-0004IG-JX for gclcip-std-proposals@m.gmane.org; Tue, 17 Feb 2015 20:52:51 +0100 Original-Received: by lbdu10 with SMTP id u10sf4469104lbd.3 for ; Tue, 17 Feb 2015 11:52:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :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=DV8djqJ+VTzCsY3+sxgVsQ+q5RyTaBHMz1gw043glk0=; b=J85xsLTZTca9B//qouUO0yTKwHbilKfRU4qLm5ea98WWEVc7y/c4vpcpIyAD4bps8j S7zZYXoYUPqlW+x15S3pWu29O1mF4tuibKmhDdSzhnTMcUmsJNbKcKjGydBB53lswfOx MmBAjLrLlddKdNQ+waT5YV8VPSMXJewlEzD9WnQd4jXTbuhwZLLIzNJRlt4EY7hWVIo3 XHWFNlD7OLWE5F8LwsuVa1y7s5sRlUj46tNN/mKWoXVDyQXo/ruL293LrRo/T23PSPw+ oI6SWoC44aS5yh5L9xeCOZ5Do4G8eb9DWMV7gmzEOIEGblS4Z9VSvc280Q038BwD9MK7 oLv X-Gm-Message-State: ALoCoQkXOmey3Mfdw4av6H5diOWO9qC+AW5wk0IbyvR3lkiNUtNWuQixJ2AuLZhQkSjNdqFjzvPY X-Received: by 10.152.19.100 with SMTP id d4mr70092lae.7.1424202771256; Tue, 17 Feb 2015 11:52:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.72.205 with SMTP id f13ls933542wiv.34.gmail; Tue, 17 Feb 2015 11:52:49 -0800 (PST) X-Received: by 10.194.110.233 with SMTP id id9mr65536365wjb.136.1424202769739; Tue, 17 Feb 2015 11:52:49 -0800 (PST) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id r19si31047889wiw.100.2015.02.17.11.52.49 for ; Tue, 17 Feb 2015 11:52:49 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (jfdmzpr04-ext.jf.intel.com [134.134.137.73]) by gondolin.macieira.info (Postfix) with ESMTPSA id 3F92F11BAB8 for ; Tue, 17 Feb 2015 11:52:49 -0800 (PST) User-Agent: KMail/4.14.4 (Linux/3.11.10-25-desktop; KDE/4.14.4; x86_64; ; ) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mail=thiago@macieira.org 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:16350 Archived-At: 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 class= =E2=80=99 PTMs at > the time it gets completed? Shouldn=E2=80=99t pointers to members of inco= mplete > classes be incomplete too? I don't know if the standard says the below code is valid or whether it has= =20 undefined- or implementation-defined behaviour. It does compile without war= nings=20 at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when= =20 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=20 question. If the above has implementation-defined behaviour, MSVC is=20 conformant; if the above is legally-valid code, then MSVC ought to fix thei= r=20 ABI... If MSVC has broken ABI *every* *single* release in the past 15 years, why= =20 hasn't it fixed the above issue, when there is a clear solution works for= =20 everyone and, moreover, is available via compile switch (the /vmg option) https://msdn.microsoft.com/en-us/library/yad46a6z.aspx --=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 --=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/. .