220 16363 <4118260.ahajs63pV4@tjmaciei-mobl4> article
Path: news.gmane.org!not-for-mail
From: Thiago Macieira <thiago@macieira.org>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Re: Pointers to members of unknown class
Date: Tue, 17 Feb 2015 23:34:10 -0800
Lines: 48
Approved: news@gmane.org
Message-ID: <4118260.ahajs63pV4@tjmaciei-mobl4>
References: <9b03a820-0ac5-4931-9825-b2fc9ef893f9@isocpp.org> <3195225.rb5WNQZqGk@tjmaciei-mobl4> <CAOfiQqmGZ9YUDhx7a-0exx6sVAGw4zYx2d9c2dcQ_g_+MSJx3w@mail.gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Trace: ger.gmane.org 1424244892 15325 80.91.229.3 (18 Feb 2015 07:34:52 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 18 Feb 2015 07:34:52 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCB4TK757YBRBFEBSGTQKGQETHLQSXQ@isocpp.org Wed Feb 18 08:34:46 2015
Return-path: <std-proposals+bncBCB4TK757YBRBFEBSGTQKGQETHLQSXQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-lb0-f199.google.com ([209.85.217.199])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCB4TK757YBRBFEBSGTQKGQETHLQSXQ@isocpp.org>)
	id 1YNz9h-0006nf-QD
	for gclcip-std-proposals@m.gmane.org; Wed, 18 Feb 2015 08:34:45 +0100
Original-Received: by lbvp9 with SMTP id p9sf6240032lbv.1
        for <gclcip-std-proposals@m.gmane.org>; Tue, 17 Feb 2015 23:34: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:from:to:subject:date:message-id:user-agent
         :in-reply-to:references:mime-version: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=rEaS1QyLnImb4+s0df/Vf0aaz/x2c+JIwKK3cB+CO0A=;
        b=FhRHcfMgavsfJp0EV6aYDSlGkiExOw4PdSMfouKXN+i+EK/gie8wtQmlKlB7C60NrI
         5wCAaZWATeY+gbnDQMq3oTOx2ZQ3vxCRg4KO3vzNELBEf4qVP2IBZIc8arG3hiMSWInt
         yg9yvUITQY94HIYFxfwZA5saG8PsummYw7cBF+Hh9klULXpI6c3kJpH7DNw2emvWp8zB
         gMPoPJl2qS3KVQFJImwicztJKmxQVFozLdScMj5nT7KmnaqeeG5a2QOqEvZlhHL9znly
         45jbPLe2h3icLGu5Mdg6B/ngwoEwhFoyycIKX8NBGMfZIhcz4uAxXJ8cc+AdPOwkFqdk
         E8Mg==
X-Gm-Message-State: ALoCoQnUkUJF8XrkyybFffLjxDXPDL5XcfJn0Zw1nobHzHB4JgALwTVbFxo/nxwVHfM5QtCj3Q/I
X-Received: by 10.180.12.146 with SMTP id y18mr125344wib.6.1424244885340;
        Tue, 17 Feb 2015 23:34:45 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.180.84.72 with SMTP id w8ls550145wiy.4.canary; Tue, 17 Feb
 2015 23:34:44 -0800 (PST)
X-Received: by 10.180.107.71 with SMTP id ha7mr109621wib.23.1424244884327;
        Tue, 17 Feb 2015 23:34:44 -0800 (PST)
Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [2a01:4f8:d13:f81:21c:14ff:fe01:12a3])
        by mx.google.com with ESMTP id ff5si33543300wib.42.2015.02.17.23.34.43
        for <std-proposals@isocpp.org>;
        Tue, 17 Feb 2015 23:34:43 -0800 (PST)
Received-SPF: pass (google.com: domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3 as permitted sender) client-ip=2a01:4f8:d13:f81:21c:14ff:fe01:12a3;
Original-Received: from tjmaciei-mobl4.localnet (jfdmzpr06-ext.jf.intel.com [134.134.137.75])
	by gondolin.macieira.info (Postfix) with ESMTPSA id C9E1511BB01
	for <std-proposals@isocpp.org>; Tue, 17 Feb 2015 23:34:42 -0800 (PST)
User-Agent: KMail/4.14.4 (Linux/3.11.10-25-desktop; KDE/4.14.4; x86_64; ; )
In-Reply-To: <CAOfiQqmGZ9YUDhx7a-0exx6sVAGw4zYx2d9c2dcQ_g_+MSJx3w@mail.gmail.com>
X-Original-Sender: thiago@macieira.org
X-Original-Authentication-Results: mx.google.com;       spf=pass (google.com:
 domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3
 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: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:16363
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/16363>

On Tuesday 17 February 2015 15:33:01 Richard Smith wrote:
> <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 for
> > 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 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'm not asking to drop the extension. I'm asking that they fix their non-
conforming behaviour. They could introduce a default that is as big as the 
Itanium C++ ABI does and provide the even-larger version when necessary. Or 
they could use the large one everywhere.

> 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.

So what they need is a "/vmm" that applies to everything except virtual 
inheritance, leaving the 3-4 pointer version for classes with virtuals. Since 
that is an extension anyway, it doesn't need to support incomplete classes.

-- 
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

-- 

--- 
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/.

.
