220 13301 <71c46372-b597-472f-a3f5-6119d7adf102@isocpp.org> article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Tighten rules for virtual override keyword combination Date: Mon, 29 Sep 2014 01:40:51 -0700 (PDT) Lines: 229 Approved: news@gmane.org Message-ID: <71c46372-b597-472f-a3f5-6119d7adf102@isocpp.org> References: <19267205-7e26-4c12-b9b4-f26ab2f99eb7@isocpp.org> <803262EF-88B4-40B0-AC9B-7C7356CDE56A@gmail.com> <54274B57.6040007@gmail.com> <542801A1.5040503@gmail.com> <86dea2ad-93c2-4cf1-9afc-99256c580a8d@isocpp.org> <4be2b4b5-7893-4408-9073-add2661ee58e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_306_1738849453.1411980051786" X-Trace: ger.gmane.org 1411980063 5383 80.91.229.3 (29 Sep 2014 08:41:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2014 08:41:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBFNWUSQQKGQEDGRXHVY@isocpp.org Mon Sep 29 10:40:56 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYWVr-0005Dj-05 for gclcip-std-proposals@m.gmane.org; Mon, 29 Sep 2014 10:40:55 +0200 Original-Received: by mail-ig0-f197.google.com with SMTP id uq10sf25005248igb.0 for ; Mon, 29 Sep 2014 01:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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 :content-type; bh=/sk3bdNr+DEpNSpqkPXwkZ0un5MNYQEUMI0SMnSBY8A=; b=BmEIGPjIJ6Em67tsNSGDBgfb+giXWG0vHLw3qJVxROVAHy/zQtxtXEj594nONr/WiF Q+5N0ZWF2lRupiMwYQrmIt9Gsk7TTTpF7ea0o3kpPWJiu4panYo17v0k+8aC8jM3bKrX 4ei2VFzcxIS8PV0OeCNGKaJmN5hF2ZgEvQuf6/d4ATgv3wJ5mfxpZPL3cxGyBUFZt2r0 HeoW3NJURVAvQeKneXM+L7FsO6nCwjGB4p2XNGWEH4Z1PWke7SZEvIBqFwoD+zNYYraD 2tENBAVDZVzTE0yc/LhakNQHQdBHR4B3/phx1VvKrpRogmxnaHyewkzaQl7qbO88i5Cv dioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to: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:content-type; bh=/sk3bdNr+DEpNSpqkPXwkZ0un5MNYQEUMI0SMnSBY8A=; b=aXRmCAnaj3vJudsqMz9rWzJQJfR549U81a3K+pqEb7sPzErhaOsiYARoR/dbo5tII/ CFSamtyBmg2mejU5XyAcsiGiJia5de99Fb5ewC3HOn5hc8jtMV2AF+f+IxwAkZPhpnl/ SL41wNGYgOrbn89eTohtbZqN+sRojt0KMs2qb1ybIMD1q5TrgYS8et1bHVbOuwOaVI9Q FZ7u8Z8CFdsNui1J0aE1RatLAHMJgMutH5eyoBA5Ejr1+YvAqaxykPWzcCOfPGoF0Y22 fIaZ9cWCXUaHwh63N5OYDwLyFbyNPW7iWUv9uo1jJL7kwp3fyFgMOGs7QiOOkk0fGm/s gA1A== X-Gm-Message-State: ALoCoQnAtagcwb4kma2LdtXIbb2jVMRgffrs1skvkTfR4y0gXJ+8/5gWhqqGc8byHIYL0W9cBxFB X-Received: by 10.182.213.105 with SMTP id nr9mr34085957obc.36.1411980054067; Mon, 29 Sep 2014 01:40:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.60.97 with SMTP id g1ls2062919igr.0.gmail; Mon, 29 Sep 2014 01:40:53 -0700 (PDT) X-Received: by 10.50.118.4 with SMTP id ki4mr732365igb.9.1411980053369; Mon, 29 Sep 2014 01:40:53 -0700 (PDT) In-Reply-To: X-Original-Sender: gmisocpp@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:13301 Archived-At: ------=_Part_306_1738849453.1411980051786 Content-Type: text/plain; charset=UTF-8 Hi Ville On Monday, September 29, 2014 8:06:16 PM UTC+13, Ville Voutilainen wrote: > > On 29 September 2014 04:54, > wrote: > > It would seem this example, while real, is just some c++11 compatibility > > code as I suspected. > > > > I have yet to see anything anywhere so far that undermines the basic > > principle that putting override and virtual on the same function is > > redundant and shouldn't be encouraged unless there is good reason. > > > > If that assertion is true, at a minimum, we can improve the status quo > by > > putting something in the isocpp faq that states that, can we not? > > > > To me it would seem a pretty clean guideline that would resolve the > > confusion that exists that both are necessary. > > Well, first of all, there's already common confusion that virtual is > necessary > for overrides, regardless of whether the override keyword exists or not. > So > this guideline of not using both of them doesn't entirely resolve all the > confusion in the world. > I don't see good reason to add to the confusion but any reasonable opportunity to minimize confusion is something I think we should try if possible. > > Your example is simply "a good reason", but it's still just > compatibility > > code, not something that would undermine the rule I'm trying to > establish. > > I also think having a switch to diagnose this redundancy in code would > be > > useful. > > > > In theory at least, we'd want to get rid of such compatibility code > > eventually. > > The code, while verbose and redundant, is completely harmless. There's > no need to get rid of it. As a bad analogy, I don't see people wanting > to get rid of 'unsigned int' because 'unsigned' will do. > Like you said, it's not the best analogy, but fwiw I think most people would agree that allowing unsigned x was a bad idea with hindsight. > > There appears to be no reason to want both override and virtual on the > same > > function beyond compatibility reasons, right? > > > Some people love writing verbose code. Some people want to write the > virtual > as a prefix for any virtual function, overridden or not. > I think we agree that virtual void x() override is the same as void x() override. Your point seems to be 'people need this for compatibility and do this because they like being verbose'. We agree on the compatibility value, but I personally think 90% of users that are typing virtual void x() override, instead of void x() override, are doing so not for compatibility reasons or a joy of verbosity, but because they aren't sure they are the same. On that basis, I think it would be valuable to get the message out in the faq that using both virtual and override in this context means the same thing and that virtual is not needed. Would you agree to that? My further aim is to get a determination (based on consensus of this forum) listed on there about which is the better style, to use both keywords or just override. The only way to find out really what is bad style though is to debate it, kill any myths, and get feedback and find consensus. So that's what I'm trying to encourage here. Your opinion on what is your style here would be useful. If we can do more, like recommending compiler vendors spot both keywords and warn, I'd be even happier as it'd make it easier for those of us that want to eliminate it in our code because we think it's bad style to do that. If the compiler could see through macros and not warn in that case, so much the better. An faq listing on this subject and consensus is something that would give vendors a mandate for bothering with such a compiler warning. What's is the consensus on this people? Thanks -- --- 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/. ------=_Part_306_1738849453.1411980051786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ville

On Monday, September 29, 2014 8:06:16 PM U= TC+13, Ville Voutilainen wrote:
On 29 September= 2014 04:54,  <gmis...@gmail.c= om> wrote:
> It would seem this example, while real, is just some c++11 compati= bility
> code as I suspected.
>
> I have yet to see anything anywhere so far that undermines the bas= ic
> principle that putting override and virtual on the same function i= s
> redundant and shouldn't be encouraged unless there is good reason.
>
> If that assertion is true, at a minimum, we can improve the status= quo by
> putting something in the isocpp faq that states that, can we not?
>
> To me it would seem a pretty clean guideline that would resolve th= e
> confusion that exists that both are necessary.

Well, first of all, there's already common confusion that virtual is ne= cessary
for overrides, regardless of whether the override keyword exists or not= .. So
this guideline of not using both of them doesn't entirely resolve all t= he
confusion in the world.
 
I don't see good reason to add to th= e confusion but any reasonable opportunity to minimize confusion is somethi= ng I think we should try if possible.


> Your example is simply "a good reason", but it's still just compat= ibility
> code, not something that would undermine the rule I'm trying to es= tablish.
> I also think having a switch to diagnose this redundancy in code w= ould be
> useful.
>
> In theory at least, we'd want to get rid of such compatibility cod= e
> eventually.

The code, while verbose and redundant, is completely harmless. There's
no need to get rid of it. As a bad analogy, I don't see people wanting
to get rid of 'unsigned int' because 'unsigned' will do.
 
Like you said, it's not the best ana= logy, but fwiw I think most people would agree that allowing unsigned = x was a bad idea with hindsight.


> There appears to be no reason to want both override and virtual on= the same
> function beyond compatibility reasons, right?


Some people love writing verbose code. Some people want to write the vi= rtual
as a prefix for any virtual function, overridden or not.

I think we agree that virtua= l void x() override is the same as  void x() override.

<= /div>
Your point seems to be 'people need this for compatibility a= nd do this because they like being verbose'.

We&nb= sp;agree on the compatibility value, but I personally think 90% of&nbs= p;users that are typing virtual void x() override, instead of voi= d x() override, are doing so not for compatibility reasons o= r a joy of verbosity, but because they aren't sure they are = the same.

On that basis, I think it would be = valuable to get the message out in the faq that using both v= irtual and override in this context means the same thing and that virt= ual is not needed. Would you agree to that?

M= y further aim is to get a determination (based on consensus = of this forum) listed on there about which is the better style, t= o use both keywords or just override.

The onl= y way to find out really what is bad style though is to debate it= , kill any myths, and get feedback and find consensus. So that's = what I'm trying to encourage here. Your opinion on what is your style here = would be useful.
 
If we can do more, like re= commending compiler vendors spot both keywords and warn, I'd= be even happier as it'd make it easier for those of us that want to e= liminate it in our code because we think it's bad style to d= o that. If the compiler could see through macros and not warn in that = case, so much the better.

An faq listing on t= his subject and consensus is something that would give vendors a manda= te for bothering with such a compiler warning.

Wha= t's is the consensus on this people?

Thanks
<= /div>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_306_1738849453.1411980051786-- .