220 7576 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Mon, 4 Nov 2013 07:46:44 +0200 Lines: 116 Approved: news@gmane.org Message-ID: References: <4608928.hBFqcpEg1D@tjmaciei-mobl2> <2334136.EQ8SoHyhLE@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc78cced96c904ea537045 X-Trace: ger.gmane.org 1383544001 23746 80.91.229.3 (4 Nov 2013 05:46:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 05:46:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBRHJ3SJQKGQEXKSLT3Q@isocpp.org Mon Nov 04 06:46:47 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VdCzu-0004wS-UE for gclcip-std-proposals@m.gmane.org; Mon, 04 Nov 2013 06:46:47 +0100 Original-Received: by mail-pa0-f72.google.com with SMTP id rd3sf11738996pab.3 for ; Sun, 03 Nov 2013 21:46: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:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=RnXE1uLlvXcuv+ADtGm64CI/57io5hZqiIEYqHY8r0s=; b=eCUkdWtgTUt2Wz0F5QzmkbUO+CTGYIGSpTlUk0a4EIT0MzFYsYHPPQ0XEtk4+8l/cB zC/QAJVApaaJ9UHj4lbBE2YjW/vhnj1ENNAB8ximgb05Nwbdni+Y08/lWCRROn1G3Avu IRk02hAq5qx12LHLiWXgGSqVsLJs5E8bChBuo43jyENkPdnxHUD4T3hHhsJ0xI/JRPpq dk58RV4rs+3AZ5jMdvn20sNg2U1qg+GAC+6PkvWFQexDlAYzz2ipWrLp/q3H+EnfSBn4 Ph7VjgOT4s/7ZSjtlmxkdygS/BcQu+0cU7qbElrT80o7OHVOigmALo9mgr10mibXHhfI ydRw== X-Gm-Message-State: ALoCoQmWPiy13b+9uyW3aze6uT/yLHtVzAM+DJDyxJBU7Vud2w3IDpWLf/F70g/CEfthVLOwsKnS X-Received: by 10.68.136.229 with SMTP id qd5mr5016240pbb.6.1383544005505; Sun, 03 Nov 2013 21:46:45 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.35.19 with SMTP id d19ls599289qej.47.gmail; Sun, 03 Nov 2013 21:46:44 -0800 (PST) X-Received: by 10.229.106.131 with SMTP id x3mr19982029qco.1.1383544004834; Sun, 03 Nov 2013 21:46:44 -0800 (PST) Original-Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [2607:f8b0:400d:c01::234]) by mx.google.com with ESMTPS id kz6si8444899qeb.32.2013.11.03.21.46.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 21:46:44 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::234 as permitted sender) client-ip=2607:f8b0:400d:c01::234; Original-Received: by mail-qc0-f180.google.com with SMTP id e9so3667019qcy.25 for ; Sun, 03 Nov 2013 21:46:44 -0800 (PST) X-Received: by 10.224.22.75 with SMTP id m11mr20171197qab.27.1383544004645; Sun, 03 Nov 2013 21:46:44 -0800 (PST) Original-Received: by 10.224.11.197 with HTTP; Sun, 3 Nov 2013 21:46:44 -0800 (PST) In-Reply-To: <2334136.EQ8SoHyhLE@tjmaciei-mobl2> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::234 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:7576 Archived-At: --047d7bdc78cced96c904ea537045 Content-Type: text/plain; charset=ISO-8859-1 On 4 November 2013 07:28, Thiago Macieira wrote: > On segunda-feira, 4 de novembro de 2013 06:41:12, Ville Voutilainen wrote: > > I still have trouble grokking the "that includes overrides" part. How > does > > adding an override change the ABI? > > See these two exceptions to overriding virtuals > > http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_with_a_covariant_return_with_different_top_address > > http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_that_doesn.27t_come_from_a_primary_base > > These two overrides are actually new virtuals in disguise under the > portable > IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we > have to take into consideration the possibility that other overrides are > actually new virtuals under other ABIs. > > That means we must treat all overrides as if they were new virtuals for the > purpose of defining the standard. > Thanks for the explanation. Also, as Billy pointed out, it would be rather weird to have any attempts to add "virtual extension methods" in one TU and not have them in another. It would be a step towards object inheritance from class inheritance, and I don't think we want to take such steps. I still don't think the (specification/implementation/teaching/etc.) cost of extension methods is palatable. There are well-known solutions to the problem that are good enough that the benefit of adding extension methods to the language is unconvincing to me. -- --- 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/. --047d7bdc78cced96c904ea537045 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 4 November 2013 07:28, Thiago Macieira <thiago@macieira.org> wrote:
On segunda-feira, 4 de nov= embro de 2013 06:41:12, Ville Voutilainen wrote:
> I still have trouble grokking the "that includes overrides" = part. How does
> adding an override change the ABI?

See these two exceptions to overriding virtuals
http://techbase.kde.org/Policies/Binary_Compatibility_Examples= #Override_a_virtual_with_a_covariant_return_with_different_top_address<= br> http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a= _virtual_that_doesn.27t_come_from_a_primary_base

These two overrides are actually new virtuals in disguise under the portabl= e
IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we=
have to take into consideration the possibility that other overrides are actually new virtuals under other ABIs.

That means we must treat all overrides as if they were new virtuals for the=
purpose of defining the standard.

Thank= s for the explanation. Also, as Billy pointed out, it would be rather weird=
to have any attempts to add "virtual extension methods" in on= e TU and not have
them in another. It would be a step towards object inheritance from class i= nheritance,
and I don't think we want to take such steps.

I still don't think the (specification/implementation/teaching/= etc.) cost of extension
methods is palatable. There are well-known solutions to the problem that ar= e good
enough that the benefit of adding extension methods to the langua= ge is unconvincing
to me.

--
 
---
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/group/std-proposals/<= /a>.
--047d7bdc78cced96c904ea537045-- .