220 37127 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Lesser 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 23:16:52 +0100 Lines: 291 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="001a1140d0c8b5152305664d19fe" X-Trace: blaine.gmane.org 1519856094 20236 195.159.176.226 (28 Feb 2018 22:14:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 22:14:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDXKNLEUTADRBVWU3TKAKGQE256CT4Q@isocpp.org Wed Feb 28 23:14:50 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f197.google.com ([74.125.82.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9zs-0004id-RH for gclcip-std-proposals@m.gmane.org; Wed, 28 Feb 2018 23:14:49 +0100 Original-Received: by mail-ot0-f197.google.com with SMTP id r32sf2205167ota.18 for ; Wed, 28 Feb 2018 14:16:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1519856215; cv=pass; d=google.com; s=arc-20160816; b=tIj9o4qYsRi/Kxjqu99+68lGqnOqSaHnqMsXqzIjigMsX9TT02N4Ti10kWKsvNpD+O YaKPwtTzRF4oCD1R/yNnjif3wmR6gaf/cYYbpDMpwf0YM9fPsWSCUThWlK9weQRBf+Rt SL1Ym2MXdDJGdORDfDZGa0kUcP+Xc9dS/nf4AHCP29PoLYLsBhBAUP8e1juo0O17NW1U JCX73O9VYhJFg3dnSAvmdee4bY6D6xoI2+uiEdbZWACqsf9qGLjsdZ1ZHrzomxBn+Kvo xmGtpGd0Jf1NzsGGn7aPtY7cB8ACN7Zuf31dpblsvoN1ghUTocp1vi6kEfbzeU8Oru2X H67g== 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=Ur2HZ6kJundsH6PLT2WeCPAhIVvAbs0Ike4irSs6iUQ=; b=WDzv9zFF1JGAg9ApI0AKzSIS7ffaDtnWlGJ5z96cqRPAe5HS4wjuOssP5GLVjxhaix tHJDo7s0KK7FllxBXTGWS71YUPm+oYXICc5EVHaWvh9qef6gtEEoKAORuLv6cGO+y0Kq fgJd0ebd+hiqXn/xa5IzdHd1D+SyGXZVK5iqL1dpgTmqgj006cTIvxWUuJe2ap3F16i3 X0x2lW33cEcOAs6HouYzw+ZuyGuhCvePqQWXgwwhBy2xYmVAh2c4mm1naO9JTSLHt9DK OV9HoJbLqETrb/yVJLLE6yS1cdhVabzmDs7Qsvi2/ggk516oeVx016CUsu6O8xWt/2dp 7Pfg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ud0/LDhZ; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@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=Ur2HZ6kJundsH6PLT2WeCPAhIVvAbs0Ike4irSs6iUQ=; b=S3ycr8bXTMqFdqTHZYbZx0jkYRRbwMS0D/KzrO3I0IRDhlJEI0y/6iMhoReDo1VmBQ 4DbfG820l2qtZ6SlhTPpgU6yPJ69TZlQM+ucPbEUkNPOD124QBUe7EAbyGVEev2t0iNb NKYiwE2xr/pv+/nF5wLCmq1LwV7HypDwuUrFaMy0eC+ogpNITL0oGyBAoWbYC1c1dTNg FTBIREg5OmOpVKeFlwMszCF2ouKEwecKGtfum1uCl4/9iSmeNQ/irGP2XY3jHFIoGSQ/ 2WWrsoJp5+DNCyeDyEqJ//M6UKNLfkVbJF4bINmtodm6uT9tEuzO6LzLJB8J72GZeKOX XGYg== 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=Ur2HZ6kJundsH6PLT2WeCPAhIVvAbs0Ike4irSs6iUQ=; b=MHT+F9g4E5N0IxcXwI6CreNtW5iDSaFPbPkMMBBbV/nOvn9s3D1j857HapBtvQHXei 5zIax+6FE0iDscSpPj/V47MhtSh8on6DlqyB3Hl/A2r106lhel6MAAufDJT7RdtddejK s6A3edCKwYaUn8siq2CsbW6tDgFta10/HMDswDuEOWluKvv8YHDfU2LEh4PCB8uUvjOV 4LEXnt/Y7H+6V+gdSX6H1njZ1+PZNmyGLeyHy/b+D/hwDH90NPnxG/nlDdfQCimtHcZ3 YXtEGKfRHMZ4LLWjqxtf4CRpw6kuIIHS6XaCE/PC0P2hIESdWpfo11AFxJCabb5Zqu12 tqpw== X-Gm-Message-State: APf1xPCaw4F0DFMcSf0gkDFYuRiUM0nB5ySv7TK0EtImbKd2BbdtdDx0 4NjiscJc51ms2RcIBJ5aLA8dTA== X-Google-Smtp-Source: AG47ELvvSTy3CrPY7NhWgPJ0+eT07/ZX0WA68rrCJwr+CDhHlvpldJ/ic0BHrUOja5nPuPANnNBAHQ== X-Received: by 10.202.198.212 with SMTP id w203mr9932801oif.44.1519856215183; Wed, 28 Feb 2018 14:16:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.52.208 with SMTP id t16ls2625478otd.22.gmail; Wed, 28 Feb 2018 14:16:53 -0800 (PST) X-Received: by 10.157.9.129 with SMTP id q1mr15167231otd.88.1519856213876; Wed, 28 Feb 2018 14:16:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519856213; cv=none; d=google.com; s=arc-20160816; b=PCS2QGiYkRXEBVc8jebpDL+rEpxw8lEIZNOrg1Pd76BtICqCQycBEN8fOmJD7TYB2J Km6+OJLCie19TmfHZTd/zOXD2k+ybEH1eqHwm/EQkOWwvr8AXZ+185ykx622jQ7Malcc zWVTH4VxyIOtK6dRfVQMflqxqWwYqSZWIyIeeIS3Wy86546uML9psr1sf1hE8f/8O+gd mZKIdlr/lbERT5b3SPLE3K0wANlYtk5OswoYUKhokRYRW8WRmCqWUS2uyUdnoiqwAL6o y93zmBY7RV0KU/RZXcfDwu0n9U7ULd5Zn8io6cPmWoDCBUnm7QQPs8n7JF+5DP57NyIk qXLg== 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=r3N6FaQ0zwuMZUoaE8AnDBPdHz0eoAi0IQFYfJVNR4I=; b=LIH9ttystXgk9o/lae8mVT59SGP4Hwn9KsU330nN/0Sz+DSfm2EAkwkAbFfkiKbAKU zqHgPNbITGbtjO8Gq6iPHmYazdTCrnacXyp3Nc0HPxnVjiTByR09Jrp8SZWYkWj+ex98 lRyrwFoOs/pUsw2kzdCtNgMreO5n59HKskNMiSPnBpU+dRjyDd+FD6RB/D8wyDex7b98 4KjODH0ajHKRMGsXzEAeNorubiiflGhzcjBCbwQabae8ckjpdXWV5pEZ6J7tL1mJJZMQ /wtqxnloadpmIy5/FV4Q7oTlPg8Opi/QPAQGNHZzHxysisfbeWg8uZLQ7JlMbKRyOPXL OPug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ud0/LDhZ; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@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 j93sor1055980otc.310.2018.02.28.14.16.53 for (Google Transport Security); Wed, 28 Feb 2018 14:16:53 -0800 (PST) Received-SPF: pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.157.37.43 with SMTP id k40mr13166833otb.299.1519856213364; Wed, 28 Feb 2018 14:16:53 -0800 (PST) Original-Received: by 10.157.94.1 with HTTP; Wed, 28 Feb 2018 14:16:52 -0800 (PST) Original-Received: by 10.157.94.1 with HTTP; Wed, 28 Feb 2018 14:16:52 -0800 (PST) In-Reply-To: X-Original-Sender: blitzrakete@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ud0/LDhZ; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@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:37127 Archived-At: --001a1140d0c8b5152305664d19fe Content-Type: text/plain; charset="UTF-8" Would you use implement for a pure virtual function with a definition? I don't think it helps readability. IMO overriding nothing is still overriding something. Adding yet another keyword to the language would needlessly complicate it further and be yet another difference that programmers will need to be aware of for no benefit at all except maybe a possible clearer terminology, which is a non-issue in my opinion. On Feb 28, 2018 11: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. 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 .. -- 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/CALmDwq1bFiV-V%2BZYHY8YfiJgBSN8v8Qk-74gOQMmRhj9ZdZzOQ%40mail.gmail.com. --001a1140d0c8b5152305664d19fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would you use implement for a pure virtual function with = a definition?

I don't thin= k it helps readability. IMO overriding nothing is still overriding somethin= g. Adding yet another keyword to the language would needlessly complicate i= t further and be yet another difference that programmers will need to be aw= are of for no benefit at all except maybe a possible clearer terminology, w= hich is a non-issue in my opinion.
On Feb 28, 2018 11:04 PM, <cristian64@gmail.com> wrote:
Pretty often I find mys= elf wanting to declare a method as implement, as
opposed to using= override.

Here an example:

<= code class=3D"m_5880001505346208548prettyprint">
#include = <iostream>

class A
{
public:
=C2=A0 =C2=A0 virtual ~A() {}
=C2=A0 =C2=A0 virtual void foo() { std::cout << "= ;A::foo" << st= d::endl; }
=C2=A0 =C2= =A0 virtual void<= span style=3D"color:rgb(0,0,0)" class=3D"m_5880001505346208548styled-by-pre= ttify"> bar() =3D 0;
};
=C2=A0
class B : public A
{
p= ublic:
=C2=A0 =C2=A0 = void foo() = o= verride { st= d::cout << "B::foo" << std::endl; }
=C2= =A0 =C2=A0 void bar() implement { s= td::cout << "B::bar" << std::endl; }
};

It helps readabilit= y. The use of override implies that an implementation
already exi= sts and is going to be overridden, which is not the case for A::bar.
implement wo= uld 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 &q= uot;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
impl= ementation needs to be executed inside the derived class' implementatio= n,
and when it must be executed.

For retro-compatibility, = override could always be used where the use of
implement i= s allowed.

On the other hand, implement would become a reserv= ed 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.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1bFiV-V%= 2BZYHY8YfiJgBSN8v8Qk-74gOQMmRhj9ZdZzOQ%40mail.gmail.com.
--001a1140d0c8b5152305664d19fe-- .