220 13272 <86dea2ad-93c2-4cf1-9afc-99256c580a8d@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: Sun, 28 Sep 2014 13:16:42 -0700 (PDT) Lines: 135 Approved: news@gmane.org Message-ID: <86dea2ad-93c2-4cf1-9afc-99256c580a8d@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_579_1815194580.1411935403633" X-Trace: ger.gmane.org 1411935414 32324 80.91.229.3 (28 Sep 2014 20:16:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Sep 2014 20:16:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBLOZUGQQKGQE77FIX6A@isocpp.org Sun Sep 28 22:16:47 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYKtj-0004gs-35 for gclcip-std-proposals@m.gmane.org; Sun, 28 Sep 2014 22:16:47 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id rl12sf12159160iec.6 for ; Sun, 28 Sep 2014 13:16:46 -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=KQh3HomFtcOZ6SP403GsZZzqsVJfHB5BVo4RoBYZ5e4=; b=cH9of4KcksaRc+jyFF5t1iE/ZOlthbsjslRjOsjd7mDhqILTTI+Am0TTSdwB/ipzCE 0Ia7hn71Qmp4lIoXX2DdZ1oF95d9zp5Ft5Kso7wlmIfi7iRfZ10J46jk515kNIiQVLDG fvAU7/WOFYInH64pwJhe+xg0i9gP17q20t555JUg6SJZrxIY+aXuvY4BYkrGTT8FHThU U6a2+o4WOLxhZ6uUP1dG0mNljD1/gBGRrbzwpX0hU+3rAXhP6BjRw7zpUVYVDyawslCR e8cy8Q3k7rWP/e4SXHbTmsmVQxKsml9yKVa5/2mnRe79BhvkXbiHbw8wd5lVMZ0dJPti 2gzA== 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=KQh3HomFtcOZ6SP403GsZZzqsVJfHB5BVo4RoBYZ5e4=; b=FTFT80Ded/dtzamGDuE4LOpNFWOlA0KWvcH7FIlADf7VELw2Q44E48MZnqJXc1ENTH cfn1Or58j8JQn6caocAcvhgKWNz8pwR9ZdcN8mEgWo8Uo4OvHwGVKOoybxjrli4JRJZ1 QUJeuNOvlHeoB5T82KAAmFNpB81x1xR4wjH5on6ZcdQV8c4iAcOFtcXeZWD/cVeIH2rR gph13POYFNr9b7ZTKcH0OdC/0uJ4MzhFxPlFduBA6qMFize+kFDHUEq43Tcj1/LbVwBQ t5/H2bkxFYH4SKENvJI6coKiggH6K+k0reIsSCC8+xTzKn9M8TPRF8exDTk+qOGz/Iy3 JlEQ== X-Gm-Message-State: ALoCoQnuU4RIIqF8cg6GWhq4t+UF2qRs6P346LxGWirRME1YnSVnIz79wWKXdX3FWv75yRNy8B5Y X-Received: by 10.182.22.201 with SMTP id g9mr31699099obf.18.1411935405950; Sun, 28 Sep 2014 13:16:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.131.131 with SMTP id om3ls1719095igb.42.gmail; Sun, 28 Sep 2014 13:16:45 -0700 (PDT) X-Received: by 10.50.18.17 with SMTP id s17mr690796igd.10.1411935405208; Sun, 28 Sep 2014 13:16:45 -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:13272 Archived-At: ------=_Part_579_1815194580.1411935403633 Content-Type: text/plain; charset=UTF-8 Hi Ville On Monday, September 29, 2014 1:47:18 AM UTC+13, Ville Voutilainen wrote: > > On 28 September 2014 15:40, germinolegrand > wrote: > > Well, actually i prefer not to mix virtual and override, because they > give > > me different informations : > > - when i see virtual, i know it's the base definition > > > > You do not know that. You may assume that in your particular programming > > style, > > but that's not what the rules say. > > > > Sure, this is only conventionnal (in use in my team). It was just a > > tentative explanation of why such a style can be interresting. The > standard > > is to standardize practices in use, not to standardize the > already-standard, > > otherwise why bother make it evolve ? > > I don't know what you mean by that, but changing the standard so that > virtual can only appear in base declarations is unacceptable. Some uses of > override are conditionalized behind macros, and there are techniques > where a virtual keyword is used on a derived class function that may or > may not be an override, when using a dependent base. In other words, > the answer to the original proposal is "no", as far as I am concerned, > since > it would mean that depending on the condition in the macro, code is or > is not diagnosed, and the answer to a hypothetical proposal that forces > virtual only on base declarations is also "no". > Would you mind elaborating on the "behind macros" comment for me please. I think you are objecting to the proposal that "if virtual and override appear on the same function it should be a warning", I'm trying to make sure I fully understand your reasons. I don't use virtual and override on functions and I'm still currently comfortable with that rule. A lot of the code I look at seems to follow that as a rule too, so I'm trying to get a clear guide one way or the other here if this is good or bad practice and why not so clear comments on the subject would be valuable in this context. Such comments are something I think should be collected up and put tin the C++ FAQ on the isocpp website. I'd really appreciate anyone who has access to making that happen do so. 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_579_1815194580.1411935403633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ville

On Monday, September 29, 2014 1:47:18 AM U= TC+13, Ville Voutilainen wrote:
On 28 September= 2014 15:40, germinolegrand <germin= o...@gmail.com> wrote:
> Well, actually i prefer not to mix virtual and override, because t= hey give
> me different informations :
> - when i see virtual, i know it's the base definition
>
> You do not know that. You may assume that in your particular progr= amming
> style,
> but that's not what the rules say.
>
> Sure, this is only conventionnal (in use in my team). It was just = a
> tentative explanation of why such a style can be interresting. The= standard
> is to standardize practices in use, not to standardize the already= -standard,
> otherwise why bother make it evolve ?

I don't know what you mean by that, but changing the standard so that
virtual can only appear in base declarations is unacceptable. Some uses= of
override are conditionalized behind macros, and there are techniques
where a virtual keyword is used on a derived class function that may or
may not be an override, when using a dependent base. In other words,
the answer to the original proposal is "no", as far as I am concerned, = since
it would mean that depending on the condition in the macro, code is or
is not diagnosed, and the answer to a hypothetical proposal that forces
virtual only on base declarations is also "no".

Would you mind elaborating on the "beh= ind macros" comment for me please. I think you are objecting to the pr= oposal that "if virtual and override appear on the same = ;function it should be a warning", I'm trying to make sure I full= y understand your reasons.

I don't use virtual and= override on functions and I'm still currently comfortable with that r= ule. A lot of the code I look at seems to follow that as a rule too, s= o I'm trying to get a clear guide one way or the other here if this is good= or bad practice and why not so clear comments on the subject would be=  valuable in this context.

Such comments are&= nbsp;something I think should be collected up and put tin the C++ FAQ on th= e isocpp website. I'd really appreciate anyone who has access to making tha= t happen do so.

Thanks

--

---
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_579_1815194580.1411935403633-- .