220 35236 <4517d88c-2eb1-455a-b9c3-22af9d698ccd@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: ambrop7@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Overriding virtual functions of member class Date: Thu, 2 Nov 2017 15:52:00 -0700 (PDT) Lines: 103 Approved: news@gmane.org Message-ID: <4517d88c-2eb1-455a-b9c3-22af9d698ccd@isocpp.org> References: <26216c34-9ff6-435b-8da5-9b21460fee1c@isocpp.org> <48759c93-8f08-458e-ac0b-ea283b75faa1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2593_247432993.1509663120352" X-Trace: blaine.gmane.org 1509663121 11926 195.159.176.226 (2 Nov 2017 22:52:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Nov 2017 22:52:01 +0000 (UTC) Cc: ambrop7@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDSJLPGLZMPBBEGD53HQKGQEXAN5R7A@isocpp.org Thu Nov 02 23:51:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAOL4-0002dZ-Ky for gclcip-std-proposals@m.gmane.org; Thu, 02 Nov 2017 23:51:54 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id k195sf564723vke.7 for ; Thu, 02 Nov 2017 15:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=zV/TTKzXAXgCu2DhyM0YOiCL8ctdScjNjMyyNp50ZVs=; b=lOjLLPTgWvu80E+0q8Tqakr9uXwILjNior3EZLFpoIwc6XTbYal3Gn+BPH5Alc1nXB 7PaqUSkmCZS2BnQiHC41ZOfcMnhnTztpCEdbOlpXyYVd2G92D6DcYwiHkLaKBmMNGlYd 8NF7Xtp5RIbMciKX/dQ3o8FYz2lo18lz679P7oHsGDQYG2Kqgqw4/vzOpCU7mP1o7RJE pPNDTMHYdpFW0yhUUjZOvdyvE2Rbm9qzjvid1c8j9JWu4o7tNpVSw7NgYcHWZJsr54E1 ejWGPrwecystFx1Nu/02gxMX455CwHJApFxiVdexqKsUjMHKHIywXYrnYxKIvSUBhi/V 5rRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=zV/TTKzXAXgCu2DhyM0YOiCL8ctdScjNjMyyNp50ZVs=; b=k9Felei1HPLlD7txUUg+qeYuKUry+Z9mc4G6vKVrR2ODapLnvjiFjT3RINW81wyEXu 07q5mueEoCtvP5R+9fuof/p4y31n/G0daf0H54gB7ZpY8MaG93dbDVUW7ENGLHDItv+z SvaMxVa89R2MaZ2N5FTcP6KUaWVsEUgIeWpCWV1yBBILdLH+6aUv/Rd2S+r6okHmDRgU dGR1w/5bdVwF+WirAK9NI+1XQqzi0+VOrt6j66MqVgexcT0cslD02QH6X3d/M5247v2a 7oubdtWlpxwZtdnhjnNyLEJDUx5KIvmS4ApOjG+jgn0E82cts2sRUfNSSPg1bHn9x5Fa PrHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=zV/TTKzXAXgCu2DhyM0YOiCL8ctdScjNjMyyNp50ZVs=; b=gX9QaE9vYvi5E90S8KvWaekY3P1gwUREDz76XIAxfnAM/zTmBv8HMM/jRAOJpu2XTa BJkRrg2IKZU9w5tjQPC1HlGhdaAmtIPJqOSUVjzU0S8tJTn62m9uYqw0ThpnScDYQNmv 4tWAujH6kk6oNw8/Z4IHpV9oo6p3UiGTr4PoMeXj8qmWLqefuTytZJM1yNgFcdmsgNg/ vYDvZnSOHa0/frMBLjZ8jsTT6/IrvDeXJ/JHbl9kTA3+jIOKxvmU7hv4oRSU19dkwsZh OpCuP+Yu7yqh5RZe5OhFWslate6ZyK89b0WcYGcAZtCj+OFkXHQ8pa7KD6+3uZhDNrIm qwUA== X-Gm-Message-State: AJaThX6DWgrw09/bEwggxvL2eElV9UdVAjvaZOZmRVAOjAG2vmcnKczB pT/368BLnCm70PHT5qBS6JsKFw== X-Google-Smtp-Source: ABhQp+SZFDh0kfuObqPVxliTyObYelBo/FhYmL/s9YBpI31XDKJLRBehgyPzISPcElhPeQqOQI5npA== X-Received: by 10.31.188.17 with SMTP id m17mr2440761vkf.99.1509663121960; Thu, 02 Nov 2017 15:52:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.47.134 with SMTP id v128ls498390vkv.14.gmail; Thu, 02 Nov 2017 15:52:00 -0700 (PDT) X-Received: by 10.31.153.21 with SMTP id b21mr367955vke.13.1509663120746; Thu, 02 Nov 2017 15:52:00 -0700 (PDT) In-Reply-To: <48759c93-8f08-458e-ac0b-ea283b75faa1@isocpp.org> X-Original-Sender: ambrop7@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:35236 Archived-At: ------=_Part_2593_247432993.1509663120352 Content-Type: multipart/alternative; boundary="----=_Part_2594_80550659.1509663120352" ------=_Part_2594_80550659.1509663120352 Content-Type: text/plain; charset="UTF-8" I have heard that argument before but I think it is only the result of people wanting correspondence with "OOP principles". There is no semantic or implementation issue. Semantically, not much more than the definition of "final overrider" changes, and implementation-wise the right vtable needs to be generated. I reject the idea that C++ must strictly follow "OOP principles". On Thursday, November 2, 2017 at 11:47:24 PM UTC+1, Nicol Bolas wrote: > > On Thursday, November 2, 2017 at 6:35:27 PM UTC-4, amb...@gmail.com wrote: >> >> Hello, >> >> Currently the only way to override a virtual function of a class A is by >> inheriting A in class B (A is a base-class subobject of B). I propose that >> the ability to override virtual functions is extended to when A is a member >> object of B. >> > > No. > > What you're proposing doesn't make sense. Inheritance represents an "is-a" > relationship; overriding virtual functions is part of that. `A` defines an > interface which all things that are `A`s implement. > > B is not an A. B& is not convertible to A& (unless you create a conversion > operator for that). So if you have an `A&`, it should not arbitrarily be > able to behave like a `B&`. > > The dynamic type of an object should be sufficient information to know > what will happen if virtual functions are called. If `A` is not a `B`, then > calling `A`'s functions should not magically cause `B` functions to be > called. > > At least, not without the `A` type having some syntax that ties it to `B`. > > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4517d88c-2eb1-455a-b9c3-22af9d698ccd%40isocpp.org. ------=_Part_2594_80550659.1509663120352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have heard that argument before but I think it is only t= he result of people wanting correspondence with "OOP principles".= There is no semantic or implementation issue. Semantically, not much more = than the definition of "final overrider" changes, and implementat= ion-wise the right vtable needs to be generated. I reject the idea that C++= must strictly follow "OOP principles".

On Thursday, Novem= ber 2, 2017 at 11:47:24 PM UTC+1, Nicol Bolas wrote:
On Thursday, November 2, 2017 at 6:3= 5:27 PM UTC-4, amb...@gmail.com wrote:
Hello,

Currently the only way= to override a virtual function of a class A is by inheriting A in class B = (A is a base-class subobject of B). I propose that the ability to override = virtual functions is extended to when A is a member object of B.

No.

What you'= ;re proposing doesn't make sense. Inheritance represents an "is-a&= quot; relationship; overriding virtual functions is part of that. `A` defin= es an interface which all things that are `A`s implement.

B is not an A. B& is not convertible to A& (unless you crea= te a conversion operator for that). So if you have an `A&`, it should n= ot arbitrarily be able to behave like a `B&`.

= The dynamic type of an object should be sufficient information to know what= will happen if virtual functions are called. If `A` is not a `B`, then cal= ling `A`'s functions should not magically cause `B` functions to be cal= led.

At least, not without the `A` type having= some syntax that ties it to `B`.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/4517d88c-2eb1-455a-b9c3-22af9d698ccd= %40isocpp.org.
------=_Part_2594_80550659.1509663120352-- ------=_Part_2593_247432993.1509663120352-- .