220 37131 article Path: news.gmane.org!.POSTED!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Use of "implement" when overriding a virtual method that does not have an implementation, yet. Date: Wed, 28 Feb 2018 19:37:54 -0500 Lines: 340 Approved: news@gmane.org Message-ID: References: <8462ee66-9e9a-4579-8246-64861bf4a349@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ce000141b7205664f1232" X-Trace: blaine.gmane.org 1519864556 30066 195.159.176.226 (1 Mar 2018 00:35:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2018 00:35:56 +0000 (UTC) To: Standard Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQIOJFW52QCRUBCEK75CO@isocpp.org Thu Mar 01 01:35:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erCCN-0007CU-FI for gclcip-std-proposals@m.gmane.org; Thu, 01 Mar 2018 01:35:51 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id w71sf2244751oia.20 for ; Wed, 28 Feb 2018 16:37:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1519864677; cv=pass; d=google.com; s=arc-20160816; b=dN1f82tikHbTm83MYFlt1mhkOWSkFT1Y/vg6AjD9xXYvGWT+z1oNEzV1RLRmsRZxfV +8Pk4BJqVlHx0+yDq4nb49h2CCaRJVLERKYvgIxYrgB3cyL/GbZObvmaXa2DUkyvleGp OyiRReCSRK35QNaQlC1lmWi8hDwSqOmDfiAn45hVAUXO8GpeoczuDt2EvmHXc5EGVfes VDdA12/hiOD3lT+SRzZctNO4ZVt9QBjDQ7HiY48aTRypsMLA1jXqFixpLWz6PzpVAXl7 uiQz+RkLjcQRSxOsZgwS9DWzhF/agsBN49RZbqvFZSwRLV7CTKgSDznh0g8RRA3fB+t9 suJQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=DbNri1LbcaQNZ0F1jdJ6f0okojZL0qeXSzS5qMBMacA=; b=YSWCS+WSHVvKDvvCcXGi13L1bBBmzXufmATJ5ZAKzPTHaeXKhTSor455tnVUfgnzub 2KvQPwox1rUkSCppGoFkJ1PYcaAvU/JLxnXMa8PEwkQhzDbmoouTxdl/GdCwSBlDqsuk r8s3VxvMck8LE/CnZM9HB/ZbWwJeG5KKZwjc3pE8Qj/GFpykEHvLsITPkVOclJ3/5mRl PLm0wyRRiSo24NkwC5yQwn3uf+eFtb4olVZSOKg1hYCt/pdP5w9pRDE40axrEcimkabi oh2K9y8y36ECvy2awfm5FOCLs8mBhCPBUlEwS+Be6gBOpZRbhF7axBaLxSakP3roZfWv Pvww== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=W/FprfDu; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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; bh=DbNri1LbcaQNZ0F1jdJ6f0okojZL0qeXSzS5qMBMacA=; b=g5bmYXndlqN6fQf9IBLDIh+o+oLx0cL1XPOO+sfg9W4L1WXwfA1zQOndE55eQHLeUn k/+Wl/85RpaB9PQxBoInMHLZToG+JhDp14HVo2jCL1/27QReDqkl8FLppYlXxBfYEfZt CSfNgREVhiEg3MqADVt6mewZh7Fep0jFibQ8B0M6VeUfn8xSUPgOGX9bIkCh4NTv6ipR xMDm/zb2TeSY0mf66ajQeFqjsSv5tYAHRrqVSTL+i0gtTJ422L2xOZkvO+eEcpqdRsOw NnGfi3Ucc3MBXZTRKwiWElNKHVqeFNbTPnYybqZX8RCswY3UXGDMZohg4Jw4yBVUch4z YEcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=DbNri1LbcaQNZ0F1jdJ6f0okojZL0qeXSzS5qMBMacA=; b=HKYNAPeapWU8oO/fQ7/fvrGxpmQr39002Hc06iyNHEx7/mwK6QFAdduiMAl+iuU8Eq mD/d92EXxMBswM6b4ZRXKuJKHyDZgNSs0ddjmYG1d6uQ5ow6kUwnAUwwhjErP3nSSmTf lSckbIghkOb8gq/DiI7x9EVIBTWkUrSB6EiKwi6gtcG2rFb+hyP+1UBHrYkQ3t9yM9SG DeoXVUNgO2OCnxy8wwhsoyesf4CIMW+RCeu2gf6cBYNTa/yDW2JB9iunAMsiw5mphuiu I06TMVu1DDAwWoph0K6ve5ZkUsQ6VjK6/lqmKxoC/6KNxXoYZAJQnj1or0QL2Mmgvf5A r7MQ== X-Gm-Message-State: APf1xPA8czui9uhIqx0Mev4XmZiLmt/PcWCjZWprjErtay0t2comiFRH iNxpbvHoos74n+QQJ2BQ6LJeQA== X-Google-Smtp-Source: AG47ELsqvqejEbgUNsM3fAXsm4YswZqEJWmVoQzYw6Zi80mvnK7SEuHnh49yM5WtsznFAjsDwhRoeQ== X-Received: by 10.202.104.73 with SMTP id d70mr10068435oic.25.1519864677203; Wed, 28 Feb 2018 16:37:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.229.206 with SMTP id c197ls704926oih.9.gmail; Wed, 28 Feb 2018 16:37:55 -0800 (PST) X-Received: by 10.202.191.214 with SMTP id p205mr2242oif.188.1519864675780; Wed, 28 Feb 2018 16:37:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519864675; cv=none; d=google.com; s=arc-20160816; b=WZeKQLnS1IS1BZBhR0cv4Mq2ZXGfKIwY7VFcmDD7ytyvOs2LmYE2bsrp0z+zYod3Kw mTnuGK0TQ+9/kykR6nSEUUS7aP8qjoURCjkAsx9Qkry6WB7CfC0UJgKhGRbNjDAr6SMm MFWHQVwQH89ABFjyj7302WsqH0KxeZSTh8An/0w78fRgNV1M0sedCySixM33uyZC2Oyb 34YY5/MHnEyReYL3Xo28+XyX8DHbhUGuZIReyPWlBxk155jsuWzb/uoSmfamztrz6pGK 03qiuKX34zcf2wgglpRGRrRPldpveLCE+MBRHjfc84CJywhby0hkA/O3mxas7OVf51Ko Fvjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=wrJ1dcNAbeGLvhrqy4j2mANzjUnu/Xg8H6FnKDnZbzc=; b=BXVYIK8bKuXsrckUxeZD9WGsE6kFBZF9ax5UrZmkc956cMxG0qdDnsCcOiZJ7elxNe P6nZyq1QD37wO9aGLEIg3tVrN+XOlsoOR5IY9JTcuOftrUFHUfB33nwDYd6V0T46bbVh +d8b80El/qrHmPc2UhxbrateqB5IPopD6wGBHvPK56RGqs+6pkJ+3auw7QMb5LnevI+z H46sd5dp1zT49GIIPVTKfVt0AewwAdEND/RMdDSXIShV4hHtD/ftLcXwRYqYRXXL1SQI ia2rJRgPockIfeL0PhMKkm5C8sUyF0wa2ett0wUNMCNHCi9zkxuYZk5BfoP9Rh8h6xVd 4yfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=W/FprfDu; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id k73sor1119208oih.271.2018.02.28.16.37.55 for (Google Transport Security); Wed, 28 Feb 2018 16:37:55 -0800 (PST) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.181.194 with SMTP id e185mr13082195oif.153.1519864675306; Wed, 28 Feb 2018 16:37:55 -0800 (PST) Original-Received: by 10.157.112.129 with HTTP; Wed, 28 Feb 2018 16:37:54 -0800 (PST) In-Reply-To: <8462ee66-9e9a-4579-8246-64861bf4a349@isocpp.org> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=W/FprfDu; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:37131 Archived-At: --001a113ce000141b7205664f1232 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 28, 2018 at 5:04 PM, wrote: > Pretty often I find myself wanting to declare a method as *implement*, as > opposed to using *override*. > > Here an example: > > #include > > class A > { > public: > virtual ~A() {} > virtual void foo() { std::cout << "A::foo" << std::endl; } > virtual void bar() = 0; > }; > > class B : public A > { > public: > void foo() override { std::cout << "B::foo" << std::endl; } > void bar() implement { std::cout << "B::bar" << std::endl; } > }; > > It helps readability. The use of *override* implies that an implementation > already exists and is going to be overridden, which is not the case for > *A::bar*. > *implement* would just fit in this case. > > If in the future an implementation for *A::bar* is provided, the compiler > will let > the developer know that an implementation is now being overridden, that is > no > longer "implementing it", but "overriding it", which may be bad. I, as a > developer, > want to be aware of that scenario. I would be able to decide whether the > base > implementation needs to be executed inside the derived class' > implementation, > and *when* it must be executed. > Never. The base implementation should never be executed inside the derived class' implementation. Don't write hierarchies like that. Don't make a convention when you can structure the code such that the compiler can guarantee it. The interface between base and derived should not be the same as the interface between user and base. See Herb's http://www.gotw.ca/publications/mill18.htm If you need derived::foo() to call base::foo(), structure it so that derived can't possibly get it wrong. ie have the user call (non-virtual) base->foo(), which does its part, then calls virtual doFoo() that derive implements. Don't derive for the sake of implementation. In general, inheritance is overused. As Sean Parent said, "inheritance is the base class of evil". > For retro-compatibility, *override* could always be used where the use of > *implement* is allowed. > > On the other hand, *implement* would become a reserved keyword of the C++ > programing language. > > > Thoughts? > > -- > 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/8462ee66-9e9a-4579- > 8246-64861bf4a349%40isocpp.org > > . > -- Be seeing you, Tony -- 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/CAOHCbiv%2BEQCcVnuY-2%2BgXfOLFq4xj5qVquZUx8VfTn7kv_85HA%40mail.gmail.com. --001a113ce000141b7205664f1232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 28, 2018 at 5:04 PM, <cristian64@gmail.com> wrote:
Pretty often I find myself wanting to declare a method as implemen= t, as
opposed to using override.

Here an example:
<= br>
<= span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-9133543598140717626styl= ed-by-prettify">#include <= iostream>

class A
{=
public:
=C2=A0 =C2=A0 virtual ~A() {}
=C2=A0 =C2=A0 virtual void foo() { std::cout << "A::foo"= << std::endl; }
=C2=A0 =C2=A0 virtual void bar() =3D 0;
};
=C2=A0
class B : public<= /span> A
{
public:
=C2=A0 =C2=A0 void foo() override { std::cout << "B::foo" << std::endl; }
=C2= =A0 =C2=A0 void bar() implement { std::cout << "B::bar" << std::endl; }
};

It helps read= ability. The use of override implies that an implementation
alrea= dy exists and is going to be overridden, which is not the case for A::bar.
implement<= /b> would just fit in this case.

If in the future an implementation<= span style=3D"font-family:arial,sans-serif"> for A::bar is provided, the compiler will let
the developer know that an implementation = is now being overridden, that is no
longer "implementing it", = but "overriding it", which may be bad. I, as a developer,
want= to be aware of that scenario. I would be able to decide whether the baseimplementation needs to be executed inside the derived class' impleme= ntation,
and when it must be executed.


Never.=C2=A0 The base implementation should never be ex= ecuted inside the derived class' implementation.
Don'= t write hierarchies like that.=C2=A0 Don't make a convention when you c= an structure the code such that the compiler can guarantee it.

The interface between base and derived should not be the same as the inter= face between user and base.
If you need derived::foo() to call base::foo(), structure it so = that derived can't possibly get it wrong.
ie have the use= r call (non-virtual) base->foo(), which does its part, then calls virtua= l doFoo() that derive implements.
=C2=A0
Don't derive for the sake of implementation.
In general, inheritance is overused.=C2=A0 As Sean Parent said, "inher= itance is the base class of evil".



For retro-compatibili= ty, override could always be used where the use of
implement is allowed.

On the other hand, implement would become a re= served keyword of the C++
programing language.


Thoughts?

--
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.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8462= ee66-9e9a-4579-8246-64861bf4a349%40isocpp.org.



--
Be seeing you,
Tony

--
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/CAOHCbiv%2BEQ= CcVnuY-2%2BgXfOLFq4xj5qVquZUx8VfTn7kv_85HA%40mail.gmail.com.
--001a113ce000141b7205664f1232-- .