220 13343 <0589bc45-a56e-494c-8385-01e23eb9a1df@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 15:35:42 -0700 (PDT) Lines: 141 Approved: news@gmane.org Message-ID: <0589bc45-a56e-494c-8385-01e23eb9a1df@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> <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: multipart/alternative; boundary="----=_Part_1801_1972247470.1412030143060" X-Trace: ger.gmane.org 1412030153 1204 80.91.229.3 (29 Sep 2014 22:35:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2014 22:35:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBQN5U6QQKGQETSYWDZY@isocpp.org Tue Sep 30 00:35:47 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYjXm-0004rg-So for gclcip-std-proposals@m.gmane.org; Tue, 30 Sep 2014 00:35:47 +0200 Original-Received: by mail-pa0-f69.google.com with SMTP id lj1sf23393606pab.0 for ; Mon, 29 Sep 2014 15:35:45 -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=fLMIV3wk4ReFAQVg6DDrwz4GC9VvVKs/TDttFnefhA4=; b=kOh2U42tMPeGAAO7t5R7Ry9PTfw+rvxSANxY2xmUzsjh68WwQ8URNPgB6goaYXWXsV GWM6bcNrOJBxsaW5Ip5ejVMV6HAeuoIphPji8H6aDwwrQyY8/xUsS/tcvEJJwpk7k+Ax +I3H8OP04/m+xAYtfgRqLTsb6DMrhzprVhREWlqXxwleg/fy8Nb3wDrylUY0APNJA76G QkKv8t9amFzHpyo4CBOOIreN6UUFrbt3Yzdp7EWrUlX9KrEuU2HYFOab78Sdejsb0ANW bphj+yDbL5TS5bTZIC48pDkMd1RT7yOg61MLryZtB04jbTTm6J0TXYba+xJJDvfFoICE 1rVA== 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=fLMIV3wk4ReFAQVg6DDrwz4GC9VvVKs/TDttFnefhA4=; b=IpZVBqmEGGpuoeQqRTUzUWgL+aSZ4lRfSFvGC3Z8LBbNrSIJALzSckXws1nBCCYlDt agrh7HWO+tJxU5I5/Kf3tnFMQi88+LAzUNKwpttwEKGDWUIQKdz35qizuN6cCOyFKFXk wkF/WG4ok9Ueg9jn4VSTn8JOPi3cgnrLey/zs5piq9snkMorROb7sXEzsVySxgSJjxlC onVG8u5+gxpi1+AgsTbQGq71o+dcJ+yENHQQAoUbygdBx3TZmvgN1I8oq8fyN0b8Q8qd CpZtrRqVoczJ7T7PuDnJJmeorM/TtN3ujsRjRHeM83YsjNhQsBQR9MIeESFSVdhgM9re 87DQ== X-Gm-Message-State: ALoCoQkPzpVCcdde12BydU/dRV/ikkuJ4p69TKp4GF2aUwC4SM5WyCsGX0jALnUuJepR+s0Q529K X-Received: by 10.70.21.229 with SMTP id y5mr38724442pde.5.1412030145800; Mon, 29 Sep 2014 15:35:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.115.38 with SMTP id jl6ls2512943igb.29.gmail; Mon, 29 Sep 2014 15:35:45 -0700 (PDT) X-Received: by 10.50.62.20 with SMTP id u20mr25589igr.15.1412030145126; Mon, 29 Sep 2014 15:35: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:13343 Archived-At: ------=_Part_1801_1972247470.1412030143060 Content-Type: text/plain; charset=UTF-8 > > > Thanks for your comments on all of that. That was very helpful to my goals. > > > 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. > Well, we sometimes have to make the case for compiler vendors before we can expect them to add warnings or whatever. That means finding consensus on the basic facts before we can expect them to listen, or just plain not miss the opportunity. The forum for that needs to have their attention and be filled with their peers or people they respect. It's only those people who have the ability and authority to take the sometimes basic but possibly sound ideas from people who don't have that same experience, and put enough meat on the bones to get the idea off the floor. I know some, like Nevin (based on his post that follows) aren't fond of this approach. But that's my view. I think this conversation has been really helpful in that regard. At a minimum, IMHO, it's got an important (to me at least) style point some attention and might get it on the c++ faq - which means it might also get the profile to appear in a Myers or Sutter book soon too lol - and with that kind of support path, that's reason enough for cause a compiler vendor (Richard Smith Doo where are you... lol) to look into the issue for a warning as they then they have a paper trail of support and reasoning to help guide their implementation - or not. That's the things they need to find inspiration to do it in the first place IMHO. Then of course you might be able to talk about deprecation one day because the tools and analysis are their to do it or think about it meaningfully. This is really an answer more for Nevin (and perhaps Richard Smith!) as much as anyone now I think about it though. Thanks for your comments Ville. 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_1801_1972247470.1412030143060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<snip>
=

Thanks for your comments on all of that. That was&= nbsp;very helpful to my goals.
 

> If we can do more, like recommending compiler vendors spot both ke= ywords and
> warn, I'd be even happier as it'd make it easier for those of us t= hat 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, s= o 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.

Well, we sometimes have to make t= he case for compiler vendors before we can expect them to add war= nings or whatever. That means finding consensus on the = basic facts before we can expect them to listen, or just plain not miss the= opportunity. The forum for that needs to have their attention and be = filled with their peers or people they respect. It's only those p= eople who have the ability and authority to take the sometimes&nb= sp;basic but possibly sound ideas from people who don't have that same= experience, and put enough meat on the bones to get the idea off the floor= ..

I know some, like Nevin (based on his post that = follows) aren't fond of this approach. But that's my view.
<= br>
I think this conversation has been really helpful in that reg= ard. At a minimum, IMHO, it's got an important (to me at least) s= tyle point some attention and might get it on the c++ faq - which mean= s it might also get the profile to appear in a Myers or Sutter bo= ok soon too lol - and with that kind of support path,&n= bsp;that's reason enough for cause a compiler vendor (Richard Smi= th Doo where are you...  lol) to look into the issue for a w= arning as they then they have a paper trail of support and r= easoning to help guide their implementation - or not. That's the = things they need to find inspiration to do it in the first place IMHO.=  Then of course you might be able to talk about deprecation one day be= cause the tools and analysis are their to do it or think about it= meaningfully.

This is really an answer more = for Nevin (and perhaps Richard Smith!) as much as anyone now I th= ink about it though.

Thanks for your comments Vill= e.

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_1801_1972247470.1412030143060-- .