220 38046 article Path: news.gmane.org!.POSTED!not-for-mail From: toma78b@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Hide inherited virtual methods (on demand) instead of trying to override them. Date: Mon, 7 May 2018 13:05:48 -0700 (PDT) Lines: 140 Approved: news@gmane.org Message-ID: References: <42a958cd-431a-48b5-b725-9793e210deff@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24293_677229058.1525723548873" X-Trace: blaine.gmane.org 1525723428 6623 195.159.176.226 (7 May 2018 20:03:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 May 2018 20:03:48 +0000 (UTC) Cc: volodymyr.ryvak@globallogic.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ6TCH7WQKBBHXDYLLQKGQEGSKX7QA@isocpp.org Mon May 07 22:03:44 2018 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 1fFmMH-0001XP-K7 for gclcip-std-proposals@m.gmane.org; Mon, 07 May 2018 22:03:41 +0200 Original-Received: by mail-vk0-f70.google.com with SMTP id a207-v6sf20651481vka.12 for ; Mon, 07 May 2018 13:05:51 -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=ao4RWr8vtGYvqEj00Bj0mRV4nMCcL+Wd436gaojHb+I=; b=Vrnot9+qmZrM+x1QQf0zO8DUvvkSa1TQ1xLVFqpApwlXj1GcqlYnvegzrUGy57cOQo AZvCBiTlzLdpCTukK4psOhvIWdVKKA5HaKWQnI88ovEge2J/Pcsm+5TysSTv8O6CdhXp weFHtZKhfGXx5II2aEj8NgmnVXe/jmM5GCex2xFCrGHHshDxszTS4QqaESSNtHbeMomI nArq2eDcMwuZSYanJ5n7YZLeDEj5NZYRG1Oi2U+r+oqEmcFqRB5LHggdu7p78OcYJeN4 ADDc8ePQKnXDJHOzn4s1O6y/n2gBATYS96NTib0FUJ5Ij2Tq2G7mvxqBh1VhrJLuulzS zeZw== 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=ao4RWr8vtGYvqEj00Bj0mRV4nMCcL+Wd436gaojHb+I=; b=NewO96LT3tTr+dVqfyHpETgdtv+AeF8CcnRgn3ZFG6FUfLXyLTXVOzozjc4I5rc74Q ofIckZucGabpMke0Ty4NM+mq+UHpugHt+34o0hU9rkqJBrHyBQT/F0ZorRZyz631VZ4S mYGmA56cAPQm7lcIh9C5eKN17F+JWXBWCxH+OisQbxg0ft5KPiNb/fbMK3rYAExGLpwv 9x30qG+nQuhWP4Y+0kTZbd/F8/ZmmA2MqDsbsq67TTFuheYhqvKg5UENH+ztQMh6JHcu 2JOv3zqNcLXXEIYxrOqacLY8ftDrWU952ec7CLdgHSjILJRnhhb0t00io3uzZziQ6bVA AE/g== 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=ao4RWr8vtGYvqEj00Bj0mRV4nMCcL+Wd436gaojHb+I=; b=i7BHADsCrR2u7upa+QII76gXVvnmvVOyAin6FLvCtGeqO1A5xVF/ICZNKZZZstx2ek qACia+f9j1zHE0lwi5iM4B9rePiYrWAEOR96HL3qon99xfCa5Sy7oEUpn+DwoEkUrbKA uGFFxbumVlVwPPIsVBxtemuFj8wN2VdSyYW/4ijmL6xQc1laanYpfWyMopbQeovx+xr3 dWvKnf8xD9bcEXgkgREds3cxbmj3IwoUqqZ4aeR5wOoi3ygdphBfoslNPY5TMu8qIJ9K S+k4LhGy8NeeKkSK8O5ug35xPunCLR0ZMF7N67bulOKOCr7SpsndahPuhdNbVlo2cHNQ lPUA== X-Gm-Message-State: ALQs6tCgV9OHjzU4+iG8/1WK8xDiwpRWoCBmEO2+mJ9BC+D5lOiCyTr4 9miSOBMLRGIaKxL3LjNHLonOOQ== X-Google-Smtp-Source: AB8JxZrWzdR+ww7woDmABeT0stdcyqEPAQJzvEFBIqufKUnCN3/7OzQw8tR3WuH3ecZo8YjVR8ELQQ== X-Received: by 10.159.36.176 with SMTP id 45mr20153950uar.81.1525723550813; Mon, 07 May 2018 13:05:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1f:ee0d:: with SMTP id m13-v6ls15694389vkh.9.gmail; Mon, 07 May 2018 13:05:49 -0700 (PDT) X-Received: by 2002:a1f:c102:: with SMTP id r2-v6mr6056116vkf.11.1525723549588; Mon, 07 May 2018 13:05:49 -0700 (PDT) In-Reply-To: <42a958cd-431a-48b5-b725-9793e210deff@isocpp.org> X-Original-Sender: toma78b@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:38046 Archived-At: ------=_Part_24293_677229058.1525723548873 Content-Type: multipart/alternative; boundary="----=_Part_24294_449211666.1525723548873" ------=_Part_24294_449211666.1525723548873 Content-Type: text/plain; charset="UTF-8" I don't think the example really illustrate why you need such feature. Why do you need a virtual function if you do not do any polymorphism ? (Cause you could just remove the virtual keyword or rename the derived class GetProduct() method, and problem solved.) On Monday, 7 May 2018 10:59:06 UTC-4, volodym...@globallogic.com wrote: > Hi. > > If method is not virtual, you can simply "hide" it in derived class: > struct A > { > void F() {} > }; > struct B: public A > { > int F() { return 0; } > }; > But if method is virtual, compiler will try to override it (instead of > hide). In case of different result types this will leads to errors: > struct A > { > virtual void F() {} > }; > struct B: public A > { > int F() { return 0; } // error, different result types > }; > In C# such things easily makes via operator "new": > class A > { > public virtual void F() { } > }; > class B: A > { > public new int F() { return 0; } > } > I propose to use the similar approach. For example operator "overload": > struct A > { > virtual void F() {} > }; > struct B: public A > { > int F() overload { return 0; } // error, different result types > }; > This will let us, for example, to use covariance (in general, as approach) > and smart pointers together: > // interface > struct IProduct {}; > struct IPipeline > { > virtual std::shared_ptr GetProduct(); > }; > > // implementation > struct Product: IProduct {}; > struct Pipeline: IPipeline > { > std::shared_ptr GetProduct() overload; > }; > > // usage > Pipeline pipeline; > std::shared_ptr produce = pipeline.GetProduct(); > > Such approach may be used only in case of "overload" operator usage to > keep backward compatibility. > -- 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/feebae63-0177-48ef-becd-233f13024013%40isocpp.org. ------=_Part_24294_449211666.1525723548873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think the example really illustrate why y= ou need such feature. Why do you need a virtual function if you do not do a= ny polymorphism ?

(Cause you could just remove the= virtual keyword or rename the derived class GetProduct() method, and probl= em solved.)

On Monday, 7 May 2018 10:59:06 UTC-4, = volodym...@globallogic.com wrote:
Hi.

If method is not virtual, you can= simply "hide" it in derived class:
struct A
{
=C2=A0=C2= =A0=C2=A0 void F() {}
};
struct B: public A
{
=C2=A0=C2=A0=C2= =A0 int F() { return 0; }
};
But if method is virtual, compiler will = try to override it (instead of hide). In case of different result types thi= s will leads to errors:
struct A
{
=C2=A0=C2=A0=C2=A0 virtual void= F() {}
};
struct B: public A
{
=C2=A0=C2=A0=C2=A0 int F() { re= turn 0; } // error, different result types
};
In C# such things easil= y makes via operator "new":
class A
{
=C2=A0=C2=A0=C2=A0= public virtual void F() { }
};
class B: A
{
=C2=A0=C2=A0=C2=A0= public new int F() { return 0; }
}
I propose to use the similar appr= oach. For example operator "overload":
struct A
{
=C2=A0= =C2=A0=C2=A0 virtual void F() {}
};
struct B: public A
{
=C2=A0= =C2=A0=C2=A0 int F() overload { return 0; } // error, different result type= s
};
This will let us, for example, to use covariance (in general, as= approach) and smart pointers together:
// interface
struct IProduct = {};
struct IPipeline
{
=C2=A0=C2=A0=C2=A0 virtual std::shared_ptr&= lt;IProduct> GetProduct();
};

// implementation
struct Prod= uct: IProduct {};
struct Pipeline: IPipeline
{
=C2=A0=C2=A0=C2=A0 = std::shared_ptr<Product> GetProduct() overload;
};

// usage=
Pipeline pipeline;
std::shared_ptr<Product> produce =3D pipeli= ne.GetProduct();

Such approach may be used only in case of "ove= rload" operator usage to keep backward compatibility.

--
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/feebae63-0177-48ef-becd-233f13024013= %40isocpp.org.
------=_Part_24294_449211666.1525723548873-- ------=_Part_24293_677229058.1525723548873-- .