220 13311 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Tighten rules for virtual override keyword combination Date: Mon, 29 Sep 2014 15:13:02 +0300 Lines: 78 Approved: news@gmane.org Message-ID: 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> <71c46372-b597-472f-a3f5-6119d7adf102@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1411992796 16238 80.91.229.3 (29 Sep 2014 12:13:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2014 12:13:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBT4ZUWQQKGQEEA3K3TY@isocpp.org Mon Sep 29 14:13:10 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYZpB-0004cY-Tw for gclcip-std-proposals@m.gmane.org; Mon, 29 Sep 2014 14:13:06 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id rd3sf27687826pab.6 for ; Mon, 29 Sep 2014 05:13:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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:content-type; bh=+ahDvG4akngpd0TYtxPhflaRF8shu7cgwxAq1h7NYzU=; b=lhmHpNXuKADSO8tQhEiOFD/SszenP33qJb1la1wJfdSVW/itRTS+k9KgRQZwHFHSNk Dx9GevaFGR/n845Y9Gl0FU4rd/s6/LSatpkxQmkL8r6iPph9I1lleRROkRd3auvdwIO+ Vvol8U2ZBQj5XHw/mqDeJfvd73OoVu2qlXKs9YVaWXO9pMRd0eX8J+KPYLsVMwI8mwVr Xzm3/95+GARffEz5jQTuBL+DVnLRGVzs/yV1Qm70pYqlBbyr0pxtpjGz5sR5PibAzgEb e/Vij2iFu/2Zcrtg0T6rC09iinrIKyZ15M2NVDh10W8SkoPLJ9r4secBGyA5n2/34P2A 15kQ== X-Gm-Message-State: ALoCoQnzRleMYdA+i4o/ljQFTIzmjAJf4sWP/El890iSOqtJBD7eKBs0Eg7GOd4TDaLBD5bIHGGp X-Received: by 10.66.156.232 with SMTP id wh8mr33201320pab.27.1411992783800; Mon, 29 Sep 2014 05:13:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.82.5 with SMTP id e5ls2165698igy.19.gmail; Mon, 29 Sep 2014 05:13:03 -0700 (PDT) X-Received: by 10.43.0.133 with SMTP id nm5mr45548888icb.55.1411992783226; Mon, 29 Sep 2014 05:13:03 -0700 (PDT) Original-Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [2607:f8b0:4001:c03::234]) by mx.google.com with ESMTPS id en16si14807798icb.5.2014.09.29.05.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 05:13:03 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::234 as permitted sender) client-ip=2607:f8b0:4001:c03::234; Original-Received: by mail-ie0-f180.google.com with SMTP id ar1so16905719iec.11 for ; Mon, 29 Sep 2014 05:13:03 -0700 (PDT) X-Received: by 10.50.77.6 with SMTP id o6mr11520816igw.25.1411992783080; Mon, 29 Sep 2014 05:13:03 -0700 (PDT) Original-Received: by 10.42.44.8 with HTTP; Mon, 29 Sep 2014 05:13:02 -0700 (PDT) In-Reply-To: <71c46372-b597-472f-a3f5-6119d7adf102@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::234 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:13311 Archived-At: On 29 September 2014 11:40, wrote: >> 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. That confusion happens among people who don't bother reading, so we have limited means to decrease their confusion. >> 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. It certainly is, and it's not a question of us agreeing on it; that's clearly how override is specified. > Your point seems to be 'people need this for compatibility and do this > because they like being verbose'. It's not quite just liking to be verbose, some coding conventions say that the virtual should be written out. > 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? Yes. I took a look at the faq and it's quite terse about these things. > 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. It's hard to change such existing styles regardless of whether they are worse or better than other styles. > 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. I don't personally like style conventions that mandate writing out virtual when override is intended. That was always foolish, because virtual doesn't change anything for an override, and it does change things for non-overrides. That's not something I have ever waged war about, since fiddling with existing conventions is a waste of time. I prefer using just override, because I prefer writing terse code. I use virtual without override if I need to make sure the function is virtual whether it is or is not an override. > 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. I don't think we need to recommend compiler vendors to add warnings for such cases. If people want such warnings, they should contribute support for such things to the open-source compilers and hope that commercial ones follow suit. -- --- 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/. .