------=_Part_2177_1670616247.1411855191475
Content-Type: text/plain; charset=UTF-8

C++ compilers allow the combination of virtual and override together. AFAIK
it serves no purpose to allow that but does causes confusion, e.g.:

http://www.reddit.com/r/cpp/comments/2hgp7i/do_you_repeat_the_virtual_keyword_in_derived/

I propose deprecating use of override and virtual together and/or requiring
or recommending the compiler  warn when both keywords are combined. A
warning like 'virtual override combination not recommended. override is
sufficient here.'

--

---
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_2177_1670616247.1411855191475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>C++ compilers&nbsp;allow the combination of virtual a=
nd override together. AFAIK it serves no purpose to allow that&nbsp;but doe=
s causes&nbsp;confusion, e.g.:</div><div><br></div><div><a href=3D"http://w=
ww.reddit.com/r/cpp/comments/2hgp7i/do_you_repeat_the_virtual_keyword_in_de=
rived/">http://www.reddit.com/r/cpp/comments/2hgp7i/do_you_repeat_the_virtu=
al_keyword_in_derived/</a></div><div><br></div><div>I propose deprecating&n=
bsp;use of&nbsp;override and virtual together and/or requiring or recommend=
ing&nbsp;the compiler&nbsp; warn&nbsp;when&nbsp;both keywords are combined.=
&nbsp;A warning like&nbsp;'virtual override combination not recommended. ov=
erride is sufficient here.'</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2177_1670616247.1411855191475--

.

On 2014-09-28, at 5:59 AM, gmisocpp@gmail.com wrote:

> C++ compilers allow the combination of virtual and override together. AFAIK it serves no purpose to allow that but does causes confusion, e.g.:

There's no confusion there, nor does virtual devalue override in any way.

Personally I would never use override *without* virtual, for the same reason I wouldn't omit virtual on an override in C++03.

--

---
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/.

.

I actually wish C++ had required that overrides used the virtual keywords. =
 It's nice to be able to look at the class and know what is going to behave=
 polymorphically.  override at the end would distinguish them, sure, but th=
en I'd have to look at the left and right side of each line instead of just=
 the left.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

Le 28/09/2014 01:21, Myriachan a =C3=A9crit :
> I actually wish C++ had required that overrides used the virtual keywords=
..  It's nice to be able to look at the class and know what is going to beha=
ve polymorphically.  override at the end would distinguish them, sure, but =
then I'd have to look at the left and right side of each line instead of ju=
st the left.
Well, actually i prefer not to mix virtual and override, because they=20
give me different informations :
- when i see virtual, i know it's the base definition
- when i see override, i know it's a redefinition.
If i were to mix them, i would be misled by the virtual at left, unless=20
i checked the right part for some override...

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--001a11c2fad0948494050419bb1a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Note that in the case of 'final', the presence or absence of 'virtual'
makes an important semantic difference: without the 'virtual', it behaves
like 'override', so you get an error if it doesn't override a virtual
method in the base class. Adding 'virtual' suppresses that error, which is
almost never what you want. This makes "use exactly one of the three" a
pretty good rule of thumb.
Le 28/09/2014 01:21, Myriachan a =C3=A9crit :

> I actually wish C++ had required that overrides used the virtual
> keywords.  It's nice to be able to look at the class and know what is goi=
ng
> to behave polymorphically.  override at the end would distinguish them,
> sure, but then I'd have to look at the left and right side of each line
> instead of just the left.
>
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
- when i see override, i know it's a redefinition.
If i were to mix them, i would be misled by the virtual at left, unless i
checked the right part for some override...

--=20

--- 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/.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--001a11c2fad0948494050419bb1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Note that in the case of &#39;final&#39;, the presence or ab=
sence of &#39;virtual&#39; makes an important semantic difference: without =
the &#39;virtual&#39;, it behaves like &#39;override&#39;, so you get an er=
ror if it doesn&#39;t override a virtual method in the base class. Adding &=
#39;virtual&#39; suppresses that error, which is almost never what you want=
.. This makes &quot;use exactly one of the three&quot; a pretty good rule of=
 thumb.</p>
<div class=3D"gmail_quot&lt;blockquote class=3D" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Le 28/09/2014 01:21, Myriacha=
n a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I actually wish C++ had required that overrides used the virtual keywords.=
=C2=A0 It&#39;s nice to be able to look at the class and know what is going=
 to behave polymorphically.=C2=A0 override at the end would distinguish the=
m, sure, but then I&#39;d have to look at the left and right side of each l=
ine instead of just the left.<br>
</blockquote>
Well, actually i prefer not to mix virtual and override, because they give =
me different informations :<br>
- when i see virtual, i know it&#39;s the base definition<br>
- when i see override, i know it&#39;s a redefinition.<br>
If i were to mix them, i would be misled by the virtual at left, unless i c=
hecked the right part for some override...<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2fad0948494050419bb1a--

.

--Apple-Mail=_87C2A59F-4EE5-4F60-8FA2-DEC6E1CD7A2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-28, at 7:42 AM, germinolegrand <germinolegrand@gmail.com> wrote:

> - when i see virtual, i know it's the base definition

I proposed a while ago on this list to define !override (or not override) t=
o provide a base definition, and !final (or not final) as a less obtuse syn=
onym for =3D 0, which would not preclude =3D default for destructors. There=
 was little interest.

C++ does not currently have a way to declare base definitions, so every der=
ived class is at the mercy of its bases and even their inaccessible members=
..


On 2014-09-28, at 1:50 PM, 'Geoffrey Romer' via ISO C++ Standard - Future P=
roposals <std-proposals@isocpp.org> wrote:

> Note that in the case of 'final', the presence or absence of 'virtual' ma=
kes an important semantic difference: without the 'virtual', it behaves lik=
e 'override', so you get an error if it doesn't override a virtual method i=
n the base class. Adding 'virtual' suppresses that error, which is almost n=
ever what you want. This makes "use exactly one of the three" a pretty good=
 rule of thumb.


I wonder why implementations don't warn on a non-override final definition,=
 and why override isn't implicit in final in the first place. It's too late=
 to change now, but where's the use case? It has the effect of reserving a =
name from derived classes, I suppose, but such a thing doesn't belong in th=
e vtable at all.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_87C2A59F-4EE5-4F60-8FA2-DEC6E1CD7A2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;28, at 7:42 AM, germinolegrand &lt;<a href=3D"mailto:germino=
legrand@gmail.com">germinolegrand@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph=
ans: auto; text-align: start; text-indent: 0px; text-transform: none; white=
-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width:=
 0px; float: none; display: inline !important;">- when i see virtual, i kno=
w it's the base definition</span><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div>=
<br><div>I proposed a while ago on this list to define <font face=3D"Courie=
r">!override</font> (or <font face=3D"Courier">not override</font>) to prov=
ide a base definition, and <font face=3D"Courier">!final</font>&nbsp;(or <f=
ont face=3D"Courier">not final</font>) as a less obtuse synonym for <font f=
ace=3D"Courier">=3D 0</font>, which would not preclude&nbsp;<font face=3D"C=
ourier">=3D default</font> for destructors. There was little interest.</div=
><div><br></div><div>C++ does not currently have a way to declare base defi=
nitions, so every derived class is at the mercy of its bases and even their=
 inaccessible members.</div><div><br></div><div><br></div><div><div>On 2014=
&ndash;09&ndash;28, at 1:50 PM, 'Geoffrey Romer' via ISO C++ Standard - Fut=
ure Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals=
@isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite">Note that in the case of 'final', the presence or ab=
sence of 'virtual' makes an important semantic difference: without the 'vir=
tual', it behaves like 'override', so you get an error if it doesn't overri=
de a virtual method in the base class. Adding 'virtual' suppresses that err=
or, which is almost never what you want. This makes "use exactly one of the=
 three" a pretty good rule of thumb.<br class=3D"Apple-interchange-newline"=
></blockquote></div><div><br></div><div>I wonder why implementations don&rs=
quo;t warn on a non-override <font face=3D"Courier">final</font> definition=
, and why <font face=3D"Courier">override</font> isn&rsquo;t implicit in <f=
ont face=3D"Courier">final</font> in the first place. It&rsquo;s too late t=
o change now, but where&rsquo;s the use case? It has the effect of reservin=
g a name from derived classes, I suppose, but such a thing doesn&rsquo;t be=
long in the vtable at all.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_87C2A59F-4EE5-4F60-8FA2-DEC6E1CD7A2E--

.

On 28 September 2014 02:42, germinolegrand <germinolegrand@gmail.com> 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.

--

---
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/.

.

On 28 September 2014 09:07, David Krauss <potswa@gmail.com> wrote:
> I wonder why implementations don=E2=80=99t warn on a non-override final d=
efinition,
> and why override isn=E2=80=99t implicit in final in the first place. It=
=E2=80=99s too late
> to change now, but where=E2=80=99s the use case? It has the effect of res=
erving a
> name from derived classes, I suppose, but such a thing doesn=E2=80=99t be=
long in the
> vtable at all.

I can use a virtual final in the base class of a template method
pattern; it prevents
derived classes from accidentally hiding the exact signature of the non-vir=
tual
entry point of the pattern.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

This is a multi-part message in MIME format.
--------------060102090608090306020102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 28/09/2014 11:07, Ville Voutilainen a =C3=A9crit :
> On 28 September 2014 02:42, germinolegrand <germinolegrand@gmail.com> wro=
te:
>> Well, actually i prefer not to mix virtual and override, because they gi=
ve
>> 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=20
tentative explanation of why such a style can be interresting. The=20
standard is to standardize practices in use, not to standardize the=20
already-standard, otherwise why bother make it evolve ?

> I proposed a while ago on this list to define !override (or not=20
> override) to provide a base definition, and !final (or not final) as a=20
> less obtuse synonym for =3D 0, which would not preclude =3D default for=
=20
> destructors. There was little interest.
the syntax seems a bit odd to me... pure would be better than !final,=20
and well I don't see the use case for !override.

Going back to the initial proposition, i would be supportive of it. But=20
forbidding virtual override would break huge code-bases, a warning would=20
be quite cool. But is the standard the good place to enforce a warning ?


--=20

---=20
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 e=
mail 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-proposa=
ls/.

--------------060102090608090306020102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 28/09/2014 11:07, Ville Voutilainen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAFk2RUbXuqC5rCp6Vs0+SrGJiQFqLkM79QT_L0scDT0GVE2YHg@mail.gmail.=
com"
      type=3D"cite">
      <pre wrap=3D"">On 28 September 2014 02:42, germinolegrand <a class=3D=
"moz-txt-link-rfc2396E" href=3D"mailto:germinolegrand@gmail.com">&lt;germin=
olegrand@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Well, actually i prefer not to mix virtual and overr=
ide, because they give
me different informations :
- when i see virtual, i know it's the base definition
</pre>
      </blockquote>
      <pre wrap=3D"">
You do not know that. You may assume that in your particular programming st=
yle,
but that's not what the rules say.
</pre>
    </blockquote>
    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 ?<br>
    <br>
    <blockquote type=3D"cite">I proposed a while ago on this list to
      define <font face=3D"Courier">!override</font> (or <font
        face=3D"Courier">not override</font>) to provide a base
      definition, and <font face=3D"Courier">!final</font>=C2=A0(or <font
        face=3D"Courier">not final</font>) as a less obtuse synonym for <fo=
nt
        face=3D"Courier">=3D 0</font>, which would not preclude=C2=A0<font
        face=3D"Courier">=3D default</font> for destructors. There was
      little interest.</blockquote>
    the syntax seems a bit odd to me... <tt>pure </tt>would be better
    than <tt>!final</tt>, and well I don't see the use case for <tt>!overri=
de</tt>.<br>
    <br>
    Going back to the initial proposition, i would be supportive of it.
    But forbidding virtual override would break huge code-bases, a
    warning would be quite cool. But is the standard the good place to
    enforce a warning ?<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------060102090608090306020102--

.

On 28 September 2014 15:40, germinolegrand <germinolegrand@gmail.com> 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".

--

---
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/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 <germino...@gmail.com
> <javascript:>> 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

<div dir=3D"ltr">Hi Ville<br><br>On Monday, September 29, 2014 1:47:18 AM U=
TC+13, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;">On 28 September=
 2014 15:40, germinolegrand &lt;<a onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vMC3f3cnyTYJ">germin=
o...@gmail.com</a>&gt; wrote:
<br>&gt; Well, actually i prefer not to mix virtual and override, because t=
hey give
<br>&gt; me different informations :
<br>&gt; - when i see virtual, i know it's the base definition
<br>&gt;
<br>&gt; You do not know that. You may assume that in your particular progr=
amming
<br>&gt; style,
<br>&gt; but that's not what the rules say.
<br>&gt;
<br>&gt; Sure, this is only conventionnal (in use in my team). It was just =
a
<br>&gt; tentative explanation of why such a style can be interresting. The=
 standard
<br>&gt; is to standardize practices in use, not to standardize the already=
-standard,
<br>&gt; otherwise why bother make it evolve ?
<br>
<br>I don't know what you mean by that, but changing the standard so that
<br>virtual can only appear in base declarations is unacceptable. Some uses=
 of
<br>override are conditionalized behind macros, and there are techniques
<br>where a virtual keyword is used on a derived class function that may or
<br>may not be an override, when using a dependent base. In other words,
<br>the answer to the original proposal is "no", as far as I am concerned, =
since
<br>it would mean that depending on the condition in the macro, code is or
<br>is not diagnosed, and the answer to a hypothetical proposal that forces
<br>virtual only on base declarations is also "no".
<br></blockquote><div><br></div><div>Would you mind elaborating on the "beh=
ind macros"&nbsp;comment for me please. I think you are objecting to the pr=
oposal&nbsp;that&nbsp;"if virtual and override appear on&nbsp;the same&nbsp=
;function it should be a warning", I'm&nbsp;trying to make sure I&nbsp;full=
y understand your reasons.</div><div><br></div><div>I don't use virtual and=
 override on&nbsp;functions and I'm still currently comfortable with that r=
ule.&nbsp;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&nbsp;clear comments on the subject would be=
&nbsp;valuable in this context.</div><div><br></div><div>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.</div><div><br></div><div>Thanks</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_579_1815194580.1411935403633--

.

On 28 September 2014 23:16,  <gmisocpp@gmail.com> wrote:
> 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.

Here's a very practical example:

https://qt.gitorious.org/qt/peter-hs-qtbase/commit/850353527f78ae6e192ba5165bde33eae2a48451

The virtual function overrides are marked virtual, and if c++11 is
enabled, Q_DECL_OVERRIDE
marks them override as well. So, requiring that to be diagnosed would
break existing
code. Potentially lots of existing code.

--

---
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_118_1072222014.1411955695203
Content-Type: text/plain; charset=UTF-8

Hi Ville

On Monday, September 29, 2014 9:47:21 AM UTC+13, Ville Voutilainen wrote:

> On 28 September 2014 23:16,  <gmis...@gmail.com <javascript:>> wrote:
> > 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.
>
> Here's a very practical example:
>
>
> https://qt.gitorious.org/qt/peter-hs-qtbase/commit/850353527f78ae6e192ba5165bde33eae2a48451
>
> The virtual function overrides are marked virtual, and if c++11 is
> enabled, Q_DECL_OVERRIDE
> marks them override as well. So, requiring that to be diagnosed would
> break existing
> code. Potentially lots of existing code.
>

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.

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.

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

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_118_1072222014.1411955695203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Ville</div><div><br>On Monday, September 29, 2014 =
9:47:21 AM UTC+13, Ville Voutilainen wrote:</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;">On 28 September 2014 23:16, &nbsp;&lt;<a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;" =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"AkIDHgtfU50=
J">gmis...@gmail.com</a>&gt; wrote:
<br>&gt; Would you mind elaborating on the "behind macros" comment for me p=
lease. I
<br>&gt; think you are objecting to the proposal that "if virtual and overr=
ide appear
<br>&gt; on the same function it should be a warning", I'm trying to make s=
ure I
<br>&gt; fully understand your reasons.
<br>
<br>Here's a very practical example:
<br>
<br><a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%=
2F%2Fqt.gitorious.org%2Fqt%2Fpeter-hs-qtbase%2Fcommit%2F850353527f78ae6e192=
ba5165bde33eae2a48451\46sa\75D\46sntz\0751\46usg\75AFQjCNHiaJD1PZ3kvtspTIG-=
K-aPZDNo3Q';return true;" onclick=3D"this.href=3D'https://www.google.com/ur=
l?q\75https%3A%2F%2Fqt.gitorious.org%2Fqt%2Fpeter-hs-qtbase%2Fcommit%2F8503=
53527f78ae6e192ba5165bde33eae2a48451\46sa\75D\46sntz\0751\46usg\75AFQjCNHia=
JD1PZ3kvtspTIG-K-aPZDNo3Q';return true;" href=3D"https://qt.gitorious.org/q=
t/peter-hs-qtbase/commit/850353527f78ae6e192ba5165bde33eae2a48451" target=
=3D"_blank">https://qt.gitorious.org/qt/<wbr>peter-hs-qtbase/commit/<wbr>85=
0353527f78ae6e192ba5165bde33<wbr>eae2a48451</a>
<br>
<br>The virtual function overrides are marked virtual, and if c++11 is
<br>enabled, Q_DECL_OVERRIDE
<br>marks them override as well. So, requiring that to be diagnosed would
<br>break existing
<br>code. Potentially lots of existing code.
<br></blockquote><div><br></div><div>It would seem this example, while real=
, is just some c++11 compatibility code as I suspected.</div><div><br></div=
><div>I have yet to see&nbsp;anything&nbsp;anywhere so far&nbsp;that underm=
ines the basic principle that putting override and virtual on the same func=
tion is redundant and shouldn't be encouraged unless there is good reason.<=
/div><div><br></div><div>If that assertion is true, at a minimum, we can im=
prove the status quo by putting something in the isocpp faq that states tha=
t, can we not?</div><div><br></div><div>To me it would seem a pretty clean =
guideline that would resolve the confusion that exists that both are necess=
ary.</div><div><br></div><div>Your example is simply "a good reason", but i=
t's still just compatibility code, not something that would undermine the r=
ule I'm trying to establish.</div><div>I also think having a switch to diag=
nose this redundancy in code would be useful.</div><div><br></div><div>In t=
heory at least, we'd want to get rid of such compatibility code eventually.=
</div><div><br></div><div>There appears to be no reason to&nbsp;want both o=
verride and virtual on&nbsp;the same&nbsp;function&nbsp;beyond compatibilit=
y reasons, right?</div><div><br></div><div>Thanks</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_118_1072222014.1411955695203--

.

On 2014-09-28, at 5:10 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> I can use a virtual final in the base class of a template method pattern; it prevents
> derived classes from accidentally hiding the exact signature of the non-virtual
> entry point of the pattern.

That's rather odd. It has nothing to do with virtual semantics. Usually in such a pattern, the user gets a handle to the abstract base. Preventing a derived class from corrupting its own interface sounds like serious idiot-proofing.

If the same pattern is used with CRTP instead of virtual dispatch, you would have the same usage scenario, and the user would certainly have access to the derived class, but the vtable would represent a high, likely prohibitive cost for an unused feature.

--

---
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/.

.

On 29 September 2014 04:54,  <gmisocpp@gmail.com> 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.

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

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

--

---
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/.

.

On 29 September 2014 07:42, David Krauss <potswa@gmail.com> wrote:
>> I can use a virtual final in the base class of a template method pattern=
; it prevents
>> derived classes from accidentally hiding the exact signature of the non-=
virtual
>> entry point of the pattern.
> That's rather odd. It has nothing to do with virtual semantics. Usually i=
n such a pattern, the user gets a handle to the abstract base. Preventing a=
 derived class from corrupting its own interface sounds like serious idiot-=
proofing.

Compilers do issue warnings for such cases, doing more of that
"serious idiot-proofing",
so apparently it has been deemed necessary enough to bother writing
book chapters
about it and implement implementation support for diagnosing it. Parts
of the hiding
cases can be made actually ill-formed by doing what I described.

> If the same pattern is used with CRTP instead of virtual dispatch, you wo=
uld have the same usage scenario, and the user would certainly have access =
to the derived class, but the vtable would represent a high, likely prohibi=
tive cost for an unused feature.

A likely prohibitive cost? Premature optimization, much?

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

------=_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,  <gmis...@gmail.com <javascript:>> 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

<div dir=3D"ltr">Hi Ville<br><br>On Monday, September 29, 2014 8:06:16 PM U=
TC+13, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;">On 29 September=
 2014 04:54, &nbsp;&lt;<a onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"a_oGNEEyhr4J">gmis...@gmail.c=
om</a>&gt; wrote:
<br>&gt; It would seem this example, while real, is just some c++11 compati=
bility
<br>&gt; code as I suspected.
<br>&gt;
<br>&gt; I have yet to see anything anywhere so far that undermines the bas=
ic
<br>&gt; principle that putting override and virtual on the same function i=
s
<br>&gt; redundant and shouldn't be encouraged unless there is good reason.
<br>&gt;
<br>&gt; If that assertion is true, at a minimum, we can improve the status=
 quo by
<br>&gt; putting something in the isocpp faq that states that, can we not?
<br>&gt;
<br>&gt; To me it would seem a pretty clean guideline that would resolve th=
e
<br>&gt; confusion that exists that both are necessary.
<br>
<br>Well, first of all, there's already common confusion that virtual is ne=
cessary
<br>for overrides, regardless of whether the override keyword exists or not=
.. So
<br>this guideline of not using both of them doesn't entirely resolve all t=
he
<br>confusion in the world.
<br></blockquote><div>&nbsp;</div><div>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.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">
<br>&gt; Your example is simply "a good reason", but it's still just compat=
ibility
<br>&gt; code, not something that would undermine the rule I'm trying to es=
tablish.
<br>&gt; I also think having a switch to diagnose this redundancy in code w=
ould be
<br>&gt; useful.
<br>&gt;
<br>&gt; In theory at least, we'd want to get rid of such compatibility cod=
e
<br>&gt; eventually.
<br>
<br>The code, while verbose and redundant, is completely harmless. There's
<br>no need to get rid of it. As a bad analogy, I don't see people wanting
<br>to get rid of 'unsigned int' because 'unsigned' will do.
<br></blockquote><div>&nbsp;</div><div>Like you said, it's not the best ana=
logy, but fwiw I think most people would agree that&nbsp;allowing unsigned =
x was a bad idea with hindsight.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;">
<br>&gt; There appears to be no reason to want both override and virtual on=
 the same
<br>&gt; function beyond compatibility reasons, right?
<br>
<br>
<br>Some people love writing verbose code. Some people want to write the vi=
rtual
<br>as a prefix for any virtual function, overridden or not.
<br></blockquote><div><br></div><div>I&nbsp;think we agree&nbsp;that virtua=
l void x() override is the same as&nbsp; void x() override.</div><div><br><=
/div><div>Your point seems to be&nbsp;'people need this for compatibility a=
nd do this because they like being verbose'.</div><div><br></div><div>We&nb=
sp;agree on the compatibility value, but I personally think&nbsp;90% of&nbs=
p;users that are&nbsp;typing&nbsp;virtual void x() override, instead of voi=
d x() override,&nbsp;are&nbsp;doing so not&nbsp;for compatibility reasons o=
r a joy of verbosity,&nbsp;but&nbsp;because&nbsp;they aren't sure they are =
the same.</div><div><br></div><div>On that basis,&nbsp;I think it would be =
valuable&nbsp;to get the message out in the&nbsp;faq&nbsp;that using both v=
irtual and override in this context&nbsp;means the same thing and that virt=
ual is&nbsp;not needed. Would you agree to that?</div><div><br></div><div>M=
y further&nbsp;aim&nbsp;is to&nbsp;get a determination (based on consensus =
of this forum)&nbsp;listed on there about which is the better&nbsp;style, t=
o use both keywords or just override.</div><div><br></div><div>The&nbsp;onl=
y way to find out really what is bad style though&nbsp;is&nbsp;to debate it=
, kill any&nbsp;myths, and get feedback and find consensus. So&nbsp;that's =
what I'm trying to encourage here. Your opinion on what is your style here =
would be useful.</div><div>&nbsp;</div><div>If we can do more, like&nbsp;re=
commending&nbsp;compiler&nbsp;vendors spot both keywords and warn,&nbsp;I'd=
 be even happier as it'd make it easier for&nbsp;those of us that want to e=
liminate it in&nbsp;our code&nbsp;because we think&nbsp;it's bad style to d=
o that. If the compiler&nbsp;could see through macros and not warn in that =
case, so much the better.</div><div><br></div><div>An faq&nbsp;listing on t=
his subject&nbsp;and consensus is something that would give vendors a manda=
te for bothering with such a compiler warning.</div><div><br></div><div>Wha=
t's is the consensus on this people?</div><div><br></div><div>Thanks</div><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_306_1738849453.1411980051786--

.

On 2014-09-29, at 3:12 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> Compilers do issue warnings for such cases, doing more of that
> "serious idiot-proofing",
> so apparently it has been deemed necessary enough to bother writing
> book chapters
> about it and implement implementation support for diagnosing it. Parts
> of the hiding
> cases can be made actually ill-formed by doing what I described.

Not sure I follow. The whole intent is to make the hiding case ill-formed, =
no?

If the implementation is specially written around it, then it can avoid gen=
erating a vtable entry, and then the standard can start to reflect that pra=
ctice too. Ideally, avoiding any implication of virtual behavior or polymor=
phism. Maybe?

Otherwise, might as well introduce a specific feature with no baggage or ov=
erhead.

>> If the same pattern is used with CRTP instead of virtual dispatch, you w=
ould have the same usage scenario, and the user would certainly have access=
 to the derived class, but the vtable would represent a high, likely prohib=
itive cost for an unused feature.
>=20
> A likely prohibitive cost? Premature optimization, much?

Mangled names of highly templated classes are a major cause of bloat. There=
 was some discussion of this in the recent "type list indexing" thread, see=
 K-Ballo's messages. My replies to him reference another earlier thread.

Throwing polymorphism into big templates isn't done lightly.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

On 29 September 2014 11:57, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-09-29, at 3:12 PM, Ville Voutilainen <ville.voutilainen@gmail.com=
> wrote:
>
>> Compilers do issue warnings for such cases, doing more of that
>> "serious idiot-proofing",
>> so apparently it has been deemed necessary enough to bother writing
>> book chapters
>> about it and implement implementation support for diagnosing it. Parts
>> of the hiding
>> cases can be made actually ill-formed by doing what I described.
>
> Not sure I follow. The whole intent is to make the hiding case ill-formed=
, no?

It's not possible to make all hiding cases ill-formed, but at least we can =
make
the ones with identical signatures ill-formed.

> If the implementation is specially written around it, then it can avoid g=
enerating a vtable entry, and then the standard can start to reflect that p=
ractice too. Ideally, avoiding any implication of virtual behavior or polym=
orphism. Maybe?
> Otherwise, might as well introduce a specific feature with no baggage or =
overhead.

These cases are nowhere near common enough to mandate a specific feature.

>>> If the same pattern is used with CRTP instead of virtual dispatch, you =
would have the same usage scenario, and the user would certainly have acces=
s to the derived class, but the vtable would represent a high, likely prohi=
bitive cost for an unused feature.
>> A likely prohibitive cost? Premature optimization, much?
> Mangled names of highly templated classes are a major cause of bloat. The=
re was some discussion of

Perhaps you should decide which of those things is your concern, the
vtbl or mangled names.

> Throwing polymorphism into big templates isn't done lightly.

Yeah, that's why I prefer measuring before spouting nonsense about a
"likely prohibitive cost".

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

On 29 September 2014 11:40,  <gmisocpp@gmail.com> 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/.

.

--f46d04462e5ecc23e9050434e2e9
Content-Type: text/plain; charset=UTF-8

On 29 September 2014 03:40, <gmisocpp@gmail.com> wrote:

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


Except the debate doesn't belong here, as it doesn't involve the standard
at all, let alone a proposal.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--f46d04462e5ecc23e9050434e2e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 29 September 2014 03:40,  <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank"=
>gmisocpp@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">The=C2=A0only way to find out really what is ba=
d style though=C2=A0is=C2=A0to debate it, kill any=C2=A0myths, and get feed=
back and find consensus. So=C2=A0that&#39;s what I&#39;m trying to encourag=
e here.</blockquote></div><br>Except the debate doesn&#39;t belong here, as=
 it doesn&#39;t involve the standard at all, let alone a proposal.<br>-- <b=
r>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 =
(847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d04462e5ecc23e9050434e2e9--

.

On 29 September 2014 17:13, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 29 September 2014 03:40, <gmisocpp@gmail.com> wrote:
>>
>> 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.
>
>
> Except the debate doesn't belong here, as it doesn't involve the standard at
> all, let alone a proposal.


Correct for the style debate part, but to be fair, this thread started
with a proposal to
deprecate a combination of virtual and override. And while eg. I and
Nevin may mostly
agree on whether it's the standard's place to dictate style-related
issues, I'm not
convinced that's a unanimous stance on a wider scale. After all, if I
trusted the committee
to do exactly the things I consider wise, I could leave them unattended. :)

--

---
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/.

.

On 2014-09-29, at 8:05 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> It's not possible to make all hiding cases ill-formed, but at least we ca=
n make
> the ones with identical signatures ill-formed.

I was just confused by the phrasing about book chapters etc.

Compilers warn about hiding a virtual method, for the sake of catching typo=
s in would-be override signatures, which isn't really the domain of idiots.

Purposely trying to override or hide the public NVI demonstrates a fundamen=
tal misunderstanding of the operation of the interface being implemented, s=
o that's quite different. Maybe there's an apparently logical reason to do =
so, I might be missing something.

> These cases are nowhere near common enough to mandate a specific feature.

Well, you mentioned it in response to my question of why final is allowed w=
ithout override. That's a feature right there.

I'm still not sure when you believe the case should apply or whether you're=
 really in favor of it at all. To be sure, the design pattern is very commo=
n.

> Perhaps you should decide which of those things is your concern, the
> vtbl or mangled names.

The main problem is that the vtable requires a mangled name to be stored as=
 an unstrippable string. Of course, it has its own overhead too.

For a template which which takes a specialization as a parameter (which des=
cribes many CRTP bases), the mangled name can be long. I've seen up to kilo=
bytes.

> Yeah, that's why I prefer measuring before spouting nonsense about a
> "likely prohibitive cost".

Well, you add the vtable of the base, several additional RTTI pointers, the=
 typeinfo object with the mangled name, and then the same for every derived=
 class.

Otherwise the base class might well have been completely empty, with no mem=
bers and only inline functions, leaving no discernible trace in the executa=
ble at all.

Bloat might not matter at all, if the end user can still download and run t=
he product, but we still value the zero-overhead principle.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

On 29 September 2014 17:58, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-09-29, at 8:05 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> It's not possible to make all hiding cases ill-formed, but at least we can make
>> the ones with identical signatures ill-formed.
>
> I was just confused by the phrasing about book chapters etc.

Meyers dedicates a fair amount of material for not hiding base functions, iirc.

> Purposely trying to override or hide the public NVI demonstrates a fundamental misunderstanding of the operation of the interface being implemented, so that's quite different. Maybe there's an apparently

Or it demonstrates a very deliberate design choice, rather than a
fundamental misunderstanding.

>> These cases are nowhere near common enough to mandate a specific feature.
> Well, you mentioned it in response to my question of why final is allowed without override. That's a feature right there.

That was an example for a potential use of the combination of virtual
and final. It's allowed because
it has potential uses, so forbidding it would need strong motivation,
and since we don't have
such strong motivation, it's allowed. Furthermore, the combination of
virtual and final is fine
for an override, so making such a combination ok for overrides but not
ok for base functions
would, again, need strong motivation.

> I'm still not sure when you believe the case should apply or whether you're really in favor of it at all. To be sure, the design pattern is very common.

I'm neither in favor or against it; it may be an applicable tool in a
rather narrow amount
of designs.

>> Yeah, that's why I prefer measuring before spouting nonsense about a
>> "likely prohibitive cost".
> Well, you add the vtable of the base, several additional RTTI pointers, the typeinfo object with the mangled name, and then the same for every derived class.

Yes. So what? None of this has any significant impact until a
measurement shows that it does.
If you don't want such overhead, by all means don't use final on a
first declaration of a virtual,
nobody's forcing you to.

--

---
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/.

.

On 2014-09-29, at 11:10 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> Or it demonstrates a very deliberate design choice, rather than a
> fundamental misunderstanding.

The deliberate choice *is* the misunderstanding. When one implements an abstract class, s/he should read its documentation, or be familiar enough beforehand, to know its public interface.

If someone caused a problem which this safety net would have prevented, I'd probably cut them more slack for arguing that it was not deliberate. Just speculating, of course.

> That was an example for a potential use of the combination of virtual
> and final. It's allowed because
> it has potential uses, so forbidding it would need strong motivation,

Not really, the alternative wouldn't have been to forbid final without override, but to let final imply override.

> If you don't want such overhead, by all means don't use final on a
> first declaration of a virtual,
> nobody's forcing you to.

Eh, at first it had sounded like there was a facility to prevent name hiding, but really there's not. So, I won't.

--

---
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/.

.

On 29 September 2014 18:18, David Krauss <potswa@gmail.com> wrote:
>> Or it demonstrates a very deliberate design choice, rather than a
>> fundamental misunderstanding.
> The deliberate choice *is* the misunderstanding. When one implements an abstract class, s/he should read its documentation, or be familiar enough beforehand, to know its public interface.

I am not talking about a misunderstanding of any kind. I'm talking
about cases where it's
necessary to hide a function in a base class, and cases where people
know what they
are doing and what the consequences are and how to alleviate the consequences.

>> That was an example for a potential use of the combination of virtual
>> and final. It's allowed because
>> it has potential uses, so forbidding it would need strong motivation,
> Not really, the alternative wouldn't have been to forbid final without override, but to let final imply

I never suggested forbidding final without override as an alternative
for anything.
And whatever the alternative would've supposed to be in some hypothetical
world, those alternatives were not suggested strongly enough, or perhaps at all,
so we didn't choose them. Changing such a decision will be hard.

--

---
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/plain; charset=UTF-8


>
> <snip>
>

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">&lt;snip&gt;<br></blockquote>=
<div><br></div><div>Thanks&nbsp;for your comments on all of that. That was&=
nbsp;very helpful to my goals.</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;">
<br>&gt; If we can do more, like recommending compiler vendors spot both ke=
ywords and
<br>&gt; warn, I'd be even happier as it'd make it easier for those of us t=
hat want
<br>&gt; to eliminate it in our code because we think it's bad style to do =
that. If
<br>&gt; the compiler could see through macros and not warn in that case, s=
o much the
<br>&gt; better.
<br>
<br>I don't think we need to recommend compiler vendors to add warnings for=
 such
<br>cases. If people want such warnings, they should contribute support
<br>for such things
<br>to the open-source compilers and hope that commercial ones follow suit.
<br></blockquote><div><br></div><div>Well,&nbsp;we sometimes have to make t=
he case for compiler vendors before&nbsp;we can expect them to&nbsp;add war=
nings or whatever.&nbsp;That means&nbsp;finding consensus&nbsp;on the&nbsp;=
basic facts before we can expect them to listen, or just plain not miss the=
 opportunity.&nbsp;The forum for that needs to have their attention and be =
filled with&nbsp;their peers or people they respect. It's&nbsp;only those p=
eople who&nbsp;have the ability and authority to take&nbsp;the sometimes&nb=
sp;basic but possibly sound ideas from&nbsp;people who don't have that same=
 experience, and put enough meat on the bones to get the idea off the floor=
..</div><div><br></div><div>I know some, like Nevin (based on his post that =
follows)&nbsp;aren't fond of this approach. But that's my view.</div><div><=
br></div><div>I think this conversation has been really helpful in that reg=
ard. At a minimum, IMHO, it's&nbsp;got an important (to me at least)&nbsp;s=
tyle point some attention and might get it on the c++ faq -&nbsp;which mean=
s&nbsp;it might also&nbsp;get the profile to appear in a Myers or Sutter bo=
ok soon too lol -&nbsp;and&nbsp;with that&nbsp;kind&nbsp;of support path,&n=
bsp;that's reason enough for&nbsp;cause a&nbsp;compiler vendor (Richard Smi=
th&nbsp;Doo where are you...&nbsp; lol)&nbsp;to look into the issue for a w=
arning as&nbsp;they&nbsp;then they have&nbsp;a paper trail of support and r=
easoning to help guide their implementation - or not.&nbsp;That's the&nbsp;=
things&nbsp;they need to find inspiration to do it in the first place IMHO.=
&nbsp;Then of course you might be able to talk about deprecation one day be=
cause the tools and analysis are their to&nbsp;do it or think&nbsp;about it=
 meaningfully.</div><div><br></div><div>This is really an answer&nbsp;more =
for&nbsp;Nevin (and perhaps Richard Smith!) as much as anyone&nbsp;now I th=
ink about it though.</div><div><br></div><div>Thanks for your comments Vill=
e.</div><div><br></div><div>Thanks</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1801_1972247470.1412030143060--

.

------=_Part_4141_1446637824.1412055395730
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, September 27, 2014 11:07:47 PM UTC-7, David Krauss wrote:
>
>
> On 2014=E2=80=9309=E2=80=9328, at 7:42 AM, germinolegrand <germino...@gma=
il.com=20
> <javascript:>> wrote:
>
> - when i see virtual, i know it's the base definition
>
>
> I proposed a while ago on this list to define !override (or not override)=
=20
> to provide a base definition, and !final (or not final) as a less obtuse=
=20
> synonym for =3D 0, which would not preclude =3D default for destructors.=
=20
> There was little interest.
>
> C++ does not currently have a way to declare base definitions, so every=
=20
> derived class is at the mercy of its bases and even their inaccessible=20
> members.
>
>
"new" would be convenient for base definitions, since it's already a=20
keyword.  Heck, C# does that, though it does have a secondary meaning.  "=
=3D=20
0" could be "pure", "abstract", etc.  If we didn't want more context=20
keywords in that position, "void" would work because I don't think there's=
=20
a grammatical ambiguity.  Or "=3D void".  Or maybe "=3D nullptr" since we h=
ave=20
"=3D 0" now.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_4141_1446637824.1412055395730
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 11:07:47 PM UTC-7, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><br><div><div>On 2014=E2=80=9309=E2=80=9328, at 7:42 AM, =
germinolegrand &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"Ubyd0o_yqM8J" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">germino...@gmail.co=
m</a>&gt; wrote:</div><br><blockquote type=3D"cite"><span style=3D"font-fam=
ily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-wei=
ght:normal;letter-spacing:normal;line-height:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:non=
e;display:inline!important">- when i see virtual, i know it's the base defi=
nition</span><br style=3D"font-family:Helvetica;font-size:12px;font-style:n=
ormal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-hei=
ght:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px"></blockquote></div><br><div>I proposed a while ag=
o on this list to define <font face=3D"Courier">!override</font> (or <font =
face=3D"Courier">not override</font>) to provide a base definition, and <fo=
nt face=3D"Courier">!final</font>&nbsp;(or <font face=3D"Courier">not final=
</font>) as a less obtuse synonym for <font face=3D"Courier">=3D 0</font>, =
which would not preclude&nbsp;<font face=3D"Courier">=3D default</font> for=
 destructors. There was little interest.</div><div><br></div><div>C++ does =
not currently have a way to declare base definitions, so every derived clas=
s is at the mercy of its bases and even their inaccessible members.</div><d=
iv><br></div></div></blockquote><div><br>"new" would be convenient for base=
 definitions, since it's already a keyword.&nbsp; Heck, C# does that, thoug=
h it does have a secondary meaning.&nbsp; "=3D 0" could be "pure", "abstrac=
t", etc.&nbsp; If we didn't want more context keywords in that position, "v=
oid" would work because I don't think there's a grammatical ambiguity.&nbsp=
; Or "=3D void".&nbsp; Or maybe "=3D nullptr" since we have "=3D 0" now.<br=
></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4141_1446637824.1412055395730--

.

On 2014-09-29, at 11:37 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 29 September 2014 18:18, David Krauss <potswa@gmail.com> wrote:
>>> Or it demonstrates a very deliberate design choice, rather than a
>>> fundamental misunderstanding.
>> The deliberate choice *is* the misunderstanding. When one implements an =
abstract class, s/he should read its documentation, or be familiar enough b=
eforehand, to know its public interface.
>=20
> I am not talking about a misunderstanding of any kind. I'm talking
> about cases where it's necessary to hide a function in a base class, and =
cases where people
> know what they are doing and what the consequences are and how to allevia=
te the consequences.

The "consequences to be alleviated" are the consequences of a potential mis=
understanding. Someone who is trying to implement the abstract class, but d=
oesn't conceptually understand its public interface well enough to avoid tr=
eading on it, is the idiot who whose error will be prevented by the legitim=
ate design choice you've described. Such a misunderstanding seems so pathol=
ogical to me as to indicate that such a person may not be competent to comp=
lete their task anyway. This sort of error is completely different from get=
ting a type or exception-specification wrong.

I suppose the choice could be approached from the perspective of defensive =
programming in a purely conceptual sense, in terms of what defective derive=
d-class specifications potentially exist, without considering what people d=
o or think. I don't subscribe to such philosophies, although allowing defec=
tive specifications to be ruled out is usually a good thing, and reserving =
a name from derived classes is certainly a reasonable feature.

> I never suggested forbidding final without override as an alternative
> for anything.

You assumed it's what I was suggesting.

> And whatever the alternative would've supposed to be in some hypothetical
> world, those alternatives were not suggested strongly enough, or perhaps =
at all,
> so we didn't choose them. Changing such a decision will be hard.

Yes, the ship has sailed. I find it hard to believe that "final implies ove=
rride" simply never occurred to the designers though.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

On 30 September 2014 09:20, David Krauss <potswa@gmail.com> wrote:
>> I never suggested forbidding final without override as an alternative
>> for anything.
> You assumed it's what I was suggesting.

You wrote "Well, you mentioned it in response to my question of why
final is allowed without override. That's a feature right there.". I
have no idea what you are or are not suggesting, but the last
time I checked, I thought I knew better what I did or did not assume
than you do.

>> And whatever the alternative would've supposed to be in some hypothetical
>> world, those alternatives were not suggested strongly enough, or perhaps at all,
>> so we didn't choose them. Changing such a decision will be hard.
> Yes, the ship has sailed. I find it hard to believe that "final implies override" simply never occurred to the designers though.

I have very vague recollection of such considerations, if any; perhaps
it did occur, sure,
but we certainly decided to keep final uncoupled from override without much ado.

--

---
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/.

.

On 30 September 2014 09:53, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>>> And whatever the alternative would've supposed to be in some hypothetical
>>> world, those alternatives were not suggested strongly enough, or perhaps at all,
>>> so we didn't choose them. Changing such a decision will be hard.
>> Yes, the ship has sailed. I find it hard to believe that "final implies override" simply never occurred to the designers though.
>
> I have very vague recollection of such considerations, if any; perhaps
> it did occur, sure,
> but we certainly decided to keep final uncoupled from override without much ado.

And there's another case where we don't even want final to imply or
require override:

template <class T> struct X : T
{
    virtual void f() final;
};

If T has a virtual f(), this would work fine. If T doesn't, we have an
ill-formed class.
So, in order to be able to say that f() is final onward from X
regardless of whether
it's virtual in T, we need the current semantics. If you want to instead say
that f() is final onward from X and it must be virtual in T, add
override into the mix,
done.

--

---
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/.

.

On 2014-09-30, at 5:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> And there's another case where we don't even want final to imply or
> require override:
>
> template <class T> struct X : T
> {
>    virtual void f() final;
> };

Good point. It's unusual to have a choice between different base classes, but this is possible.

--

---
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/.

.