Topic: In-class definition of pure virtual functions


Author: Columbo <r.hl@gmx.net>
Date: Wed, 22 Apr 2015 02:55:31 -0700 (PDT)
Raw View
------=_Part_5721_130950543.1429696531963
Content-Type: multipart/alternative;
 boundary="----=_Part_5722_1862521673.1429696531963"

------=_Part_5722_1862521673.1429696531963
Content-Type: text/plain; charset=UTF-8

Good morning. Is there any technical reason why

virtual void foo() = 0 {};

is not allowed? The grammar can be adjusted, and parsers seem to deal fine
with it: VC++ even allows this as an extension.

I'd propose to adjust* function-definition* to include *pure-specifier*s.
Would such a proposal be successful?

--

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

<div dir=3D"ltr">Good morning. Is there any technical reason why <br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">0</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div><br>is not allowed? The grammar can be adjusted, and parsers seem =
to deal fine with it: VC++ even allows this as an extension.<br><br>I'd pro=
pose to adjust<i> function-definition</i> to include <i>pure-specifier</i>s=
.. Would such a proposal be successful?<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 />

------=_Part_5722_1862521673.1429696531963--
------=_Part_5721_130950543.1429696531963--

.


Author: "Francis (Grizzly) Smit" <grizzlysmit@gmail.com>
Date: Wed, 22 Apr 2015 20:40:09 +1000
Raw View
This is a multi-part message in MIME format.
--------------080106090500000809040607
Content-Type: text/plain; charset=UTF-8; format=flowed



On 22/04/15 19:55, Columbo wrote:
> Good morning. Is there any technical reason why
>
> |
> virtualvoidfoo()=0{};
> |
>

what does this mean ??


> is not allowed? The grammar can be adjusted, and parsers seem to deal
> fine with it: VC++ even allows this as an extension.
>
> I'd propose to adjust/function-definition/ to include
> /pure-specifier/s. Would such a proposal be successful?
> --

--

    .~.     In my life God comes first....
    /V\         but Linux is pretty high after that :-D
   /( )\    Francis (Grizzly) Smit
   ^^-^^    http://www.smit.id.au/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GM/CS/H/P/S/IT/L d- s+:+ a++ C++++ UL++++$ P++ L+++$ E--- W++
N W--- M-- V-- PE- PGP t+ 5-- X-- R- tv b++++ D-
G e++ h+ y?
------END GEEK CODE BLOCK------
http://www.geekcode.com/

--

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

--------------080106090500000809040607
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 22/04/15 19:55, Columbo wrote:<br>
    </div>
    <blockquote
      cite="mid:eec88219-93b2-4c36-b4b2-8c7aa96afa60@isocpp.org"
      type="cite">
      <div dir="ltr">Good morning. Is there any technical reason why <br>
        <br>
        <div class="prettyprint" style="background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class="prettyprint">
            <div class="subprettyprint"><span style="color: #008;"
                class="styled-by-prettify">virtual</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #008;" class="styled-by-prettify">void</span><span
                style="color: #000;" class="styled-by-prettify"> foo</span><span
                style="color: #660;" class="styled-by-prettify">()</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">=</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #066;" class="styled-by-prettify">0</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">{};</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    <br>
    what does this mean ?? <br>
    <br>
    <br>
    <blockquote
      cite="mid:eec88219-93b2-4c36-b4b2-8c7aa96afa60@isocpp.org"
      type="cite">
      <div dir="ltr">is not allowed? The grammar can be adjusted, and
        parsers seem to deal fine with it: VC++ even allows this as an
        extension.<br>
        <br>
        I'd propose to adjust<i> function-definition</i> to include <i>pure-specifier</i>s.
        Would such a proposal be successful?<br>
      </div>
      -- <br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <pre>   .~.     In my life God comes first....
   /V\         but Linux is pretty high after that :-D
  /( )\    Francis (Grizzly) Smit
  ^^-^^    <a class="moz-txt-link-freetext" href="http://www.smit.id.au/">http://www.smit.id.au/</a>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GM/CS/H/P/S/IT/L d- s+:+ a++ C++++ UL++++$ P++ L+++$ E--- W++
N W--- M-- V-- PE- PGP t+ 5-- X-- R- tv b++++ D-
G e++ h+ y?
------END GEEK CODE BLOCK------
<a class="moz-txt-link-freetext" href="http://www.geekcode.com/">http://www.geekcode.com/</a>
</pre>
    </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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------080106090500000809040607--

.


Author: Columbo <r.hl@gmx.net>
Date: Wed, 22 Apr 2015 04:01:52 -0700 (PDT)
Raw View
------=_Part_773_2114736285.1429700512270
Content-Type: multipart/alternative;
 boundary="----=_Part_774_1518384145.1429700512270"

------=_Part_774_1518384145.1429700512270
Content-Type: text/plain; charset=UTF-8


Am Mittwoch, 22. April 2015 11:40:16 UTC+1 schrieb Francis Grizzly Smit:
>
>
>
> On 22/04/15 19:55, Columbo wrote:
>
> Good morning. Is there any technical reason why
>
>  virtual void foo() = 0 {};
>
>
> what does this mean ??
>

This defines a pure virtual member function foo.
This syntax could be particularly useful for destructors:

virtual ~MyClass() = 0 = default;

Looks ridiculous, yes, but that is compensated for by not having to provide
a definition outside the class one.



--

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

<div dir=3D"ltr"><br>Am Mittwoch, 22. April 2015 11:40:16 UTC+1 schrieb Fra=
ncis Grizzly Smit:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <br>
    <div>On 22/04/15 19:55, Columbo wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">Good morning. Is there any technical reason why <br>
        <br>
        <div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
            <div><span style=3D"color:#008">virtual</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#000"> foo</span><span style=3D"color:#660">()</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#066">0</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">{};</span><span style=3D"color:#000"><br>
              </span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    <br>
    what does this mean ?? </div></blockquote><div><br>This defines a pure =
virtual member function <code>foo.</code><br>This syntax could be particula=
rly useful for destructors:<br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code>
            <div><span style=3D"color:#008">virtual</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">~MyClass</span><span style=3D"=
color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
066">0</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D default;</span><span style=3D"color:#000"><br>
              </span></div>
          </code></div><br>Looks ridiculous, yes, but that is compensated f=
or by not having to provide a definition outside the class one.<br>&nbsp;</=
div><div>&nbsp;</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_774_1518384145.1429700512270--
------=_Part_773_2114736285.1429700512270--

.


Author: Henrik Vallgren <henrik.vallgren@streamspace.com>
Date: Wed, 22 Apr 2015 13:11:48 +0200
Raw View
--Apple-Mail=_88C7B2C5-4CF2-4582-8D9B-698F21CEAD65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Hi,

I don=E2=80=99t see the point in this: the =E2=80=9D=3D0=E2=80=9D part says=
 that you will not provide an=20
implementation for this class and then you add an empty one?

Why don=E2=80=99t you use

 virtual void foo() {}

Kind regards,
Henrik


> 22 apr 2015 kl. 11:55 skrev Columbo <r.hl@gmx.net>:
>=20
> Good morning. Is there any technical reason why=20
>=20
> virtual void foo() =3D 0 {};
>=20
> is not allowed? The grammar can be adjusted, and parsers seem to deal fin=
e with it: VC++ even allows this as an extension.
>=20
> I'd propose to adjust function-definition to include pure-specifiers. Wou=
ld such a proposal be successful?
>=20
> --=20
>=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=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <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/.

--Apple-Mail=_88C7B2C5-4CF2-4582-8D9B-698F21CEAD65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Hi=
,</div><div class=3D""><br class=3D""></div><div class=3D"">I don=E2=80=99t=
 see the point in this: the =E2=80=9D=3D0=E2=80=9D part says that you will =
not provide an&nbsp;</div><div class=3D"">implementation for this class and=
 then you add an empty one?</div><div class=3D""><br class=3D""></div><div =
class=3D"">Why don=E2=80=99t you use</div><div class=3D""><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 136);"><br class=3D""></span></=
div><div class=3D""><span class=3D"styled-by-prettify"><span class=3D"Apple=
-tab-span" style=3D"white-space: pre;"> </span>virtual</span><span style=3D=
"background-color: rgb(250, 250, 250);" class=3D"">&nbsp;</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">void</span><span s=
tyle=3D"background-color: rgb(250, 250, 250);" class=3D"">&nbsp;</span><spa=
n style=3D"background-color: rgb(250, 250, 250);" class=3D"">foo</span><spa=
n class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">()</span>=
<span style=3D"background-color: rgb(250, 250, 250);" class=3D"">&nbsp;</sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{}=
</span></div><div class=3D""><br class=3D""></div><div class=3D"">Kind rega=
rds,</div><div class=3D"">Henrik</div><div class=3D""><br class=3D""></div>=
<br class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">22=
 apr 2015 kl. 11:55 skrev Columbo &lt;<a href=3D"mailto:r.hl@gmx.net" class=
=3D"">r.hl@gmx.net</a>&gt;:</div><br class=3D"Apple-interchange-newline"><d=
iv class=3D""><div dir=3D"ltr" class=3D"">Good morning. Is there any techni=
cal reason why <br class=3D""><br class=3D""><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">virtual</span> <span style=3D"color: #008;" class=3D"styled-by-prettify"=
>void</span> foo<span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span> <span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n> <span style=3D"color: #066;" class=3D"styled-by-prettify">0</span> <span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><br class=3D=
""></code></div><br class=3D"">is not allowed? The grammar can be adjusted,=
 and parsers seem to deal fine with it: VC++ even allows this as an extensi=
on.<br class=3D""><br class=3D"">I'd propose to adjust<i class=3D""> functi=
on-definition</i> to include <i class=3D"">pure-specifier</i>s. Would such =
a proposal be successful?<br class=3D""></div><div class=3D""><br class=3D"=
webkit-block-placeholder"></div>

-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></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=_88C7B2C5-4CF2-4582-8D9B-698F21CEAD65--

.


Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 22 Apr 2015 14:17:22 +0300
Raw View
On Wednesday 22 April 2015 13:11:48 Henrik Vallgren wrote:
> Hi,
>=20
> I don=E2=80=99t see the point in this: the =E2=80=9D=3D0=E2=80=9D part sa=
ys that you will not provide
> an implementation for this class and then you add an empty one?

Pure virtual (=3D 0) means the function must be defined in the derived clas=
s. It=20
does not mean it must not have a body, although sometimes it _may_ not have=
=20
one. Pure virtual destructors, for instance, are possible and must have a=
=20
body, but the body must be defined out-of-class currently.

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

.


Author: Columbo <r.hl@gmx.net>
Date: Wed, 22 Apr 2015 04:31:33 -0700 (PDT)
Raw View
------=_Part_5782_2019843229.1429702293799
Content-Type: multipart/alternative;
 boundary="----=_Part_5783_83658027.1429702293799"

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

Am Mittwoch, 22. April 2015 12:11:54 UTC+1 schrieb HenrikVallgren:
>
> Hi,
>
> I don=E2=80=99t see the point in this: the =E2=80=9D=3D0=E2=80=9D part sa=
ys that you will not=20
> provide an=20
> implementation for this class and then you add an empty one?
>
=20
Andrey described it pretty well: The =3D0 part indicates that this is a *pu=
re=20
*virtual function. =C2=A710.4/2:

A pure virtual function need be defined only if called with, or as if with=
=20
> (12.4), the *qualified-id* syntax (5.1).
>

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

<div dir=3D"ltr">Am Mittwoch, 22. April 2015 12:11:54 UTC+1 schrieb HenrikV=
allgren:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word"><div>Hi,</div><div><br></div><div>I don=E2=80=99t see the poi=
nt in this: the =E2=80=9D=3D0=E2=80=9D part says that you will not provide =
an&nbsp;</div><div>implementation for this class and then you add an empty =
one?</div></div></blockquote><div>&nbsp;</div><div>Andrey described it pret=
ty well: The =3D0 part indicates that this is a <i>pure </i>virtual functio=
n. =C2=A710.4/2:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_=
quote">A pure virtual function need be defined only if called with, or as i=
f with (12.4), the <i>qualified-id</i> syntax (5.1).<br></blockquote><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_5783_83658027.1429702293799--
------=_Part_5782_2019843229.1429702293799--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 22 Apr 2015 09:32:16 -0500
Raw View
--089e01177205186e810514510a43
Content-Type: text/plain; charset=UTF-8

On 22 April 2015 at 06:01, Columbo <r.hl@gmx.net> wrote:

>
> This defines a pure virtual member function foo.
> This syntax could be particularly useful for destructors:
>
> virtual ~MyClass() = 0 = default;
>
> Looks ridiculous, yes, but that is compensated for by not having to
> provide a definition outside the class one.
>

Given that *every* derived class will generate a destructor, this is
ridiculous.  Why can't this particular use case (not being able to
instantiate the base class) be done today with protected constructors?
--
 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/.

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

<div dir=3D"ltr">On 22 April 2015 at 06:01, Columbo <span dir=3D"ltr">&lt;<=
a href=3D"mailto:r.hl@gmx.net" target=3D"_blank">r.hl@gmx.net</a>&gt;</span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br></span><div>Thi=
s defines a pure virtual member function <code>foo.</code><br>This syntax c=
ould be particularly useful for destructors:<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code>
            <div><span style=3D"color:#008">virtual</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">~MyClass</span><span style=3D"=
color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
066">0</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D default;</span><span style=3D"color:#000"><br>
              </span></div>
          </code></div><br>Looks ridiculous, yes, but that is compensated f=
or by not having to provide a definition outside the class one.<br></div></=
div></blockquote><div><br></div><div>Given that <i>every</i>=C2=A0derived c=
lass will generate a destructor, this is ridiculous.=C2=A0 Why can&#39;t th=
is particular use case (not being able to instantiate the base class) be do=
ne today with protected constructors?</div></div>-- <br><div class=3D"gmail=
_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=C2=A0 (847) 691-1404</div>
</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 />

--089e01177205186e810514510a43--

.


Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 17:35:06 +0200
Raw View
2015-04-22 16:32 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> On 22 April 2015 at 06:01, Columbo <r.hl@gmx.net> wrote:
>>
>>
>> This defines a pure virtual member function foo.
>> This syntax could be particularly useful for destructors:
>>
>> virtual ~MyClass() = 0 = default;
>>
>> Looks ridiculous, yes, but that is compensated for by not having to
>> provide a definition outside the class one.
>
>
> Given that every derived class will generate a destructor, this is
> ridiculous.  Why can't this particular use case (not being able to
> instantiate the base class) be done today with protected constructors?
>

I am not sure whether this is *the* usecase I have in mind for =0 on
destructors. My prime usecase for it would be to make a class abstract
without having the programmer of the derived class to write an
implementation of the method (the compiler does it itself).
Particularly usable for "marker interfaces". For just preventing
instantiation, abusing "=0" looks a bit like overkill.

--

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

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 22 Apr 2015 10:41:26 -0500
Raw View
--001a11349500651fb705145201e5
Content-Type: text/plain; charset=UTF-8

On 22 April 2015 at 10:35, Johannes Schaub <schaub.johannes@googlemail.com>
wrote:

> 2015-04-22 16:32 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> > On 22 April 2015 at 06:01, Columbo <r.hl@gmx.net> wrote:
> >> virtual ~MyClass() = 0 = default;
> > Why can't this particular use case (not being able to
> > instantiate the base class) be done today with protected constructors?
>
> I am not sure whether this is *the* usecase I have in mind for =0 on
> destructors. My prime usecase for it would be to make a class abstract
> without having the programmer of the derived class to write an
> implementation of the method (the compiler does it itself).
>

Again, why don't protected constructors cover this case?  I'm just not
seeing it.
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
2 April 2015 at 10:35, Johannes Schaub <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johannes@googl=
email.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">2015-04-22 16:32 GMT+02:00 Nevin Liber &lt;<a href=3D"mailto:nevin=
@eviloverlord.com">nevin@eviloverlord.com</a>&gt;:<br>
&gt; On 22 April 2015 at 06:01, Columbo &lt;<a href=3D"mailto:r.hl@gmx.net"=
>r.hl@gmx.net</a>&gt; wrote:<br>&gt;&gt; virtual ~MyClass() =3D 0 =3D defau=
lt;<br>&gt; Why can&#39;t this particular use case (not being able to<br>
&gt; instantiate the base class) be done today with protected constructors?=
<br><br>
</span>I am not sure whether this is *the* usecase I have in mind for =3D0 =
on<br>
destructors. My prime usecase for it would be to make a class abstract<br>
without having the programmer of the derived class to write an<br>
implementation of the method (the compiler does it itself).<br></blockquote=
><div><br></div><div>Again, why don&#39;t protected constructors cover this=
 case?=C2=A0 I&#39;m just not seeing it.</div></div>-- <br><div class=3D"gm=
ail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;=C2=A0 (847) 691-1404</div>
</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 />

--001a11349500651fb705145201e5--

.


Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 17:49:37 +0200
Raw View
2015-04-22 17:41 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> On 22 April 2015 at 10:35, Johannes Schaub <schaub.johannes@googlemail.com>
> wrote:
>>
>> 2015-04-22 16:32 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
>> > On 22 April 2015 at 06:01, Columbo <r.hl@gmx.net> wrote:
>> >> virtual ~MyClass() = 0 = default;
>> > Why can't this particular use case (not being able to
>> > instantiate the base class) be done today with protected constructors?
>>
>> I am not sure whether this is *the* usecase I have in mind for =0 on
>> destructors. My prime usecase for it would be to make a class abstract
>> without having the programmer of the derived class to write an
>> implementation of the method (the compiler does it itself).
>
>
> Again, why don't protected constructors cover this case?  I'm just not
> seeing it.
>

You still need a virtual destructor to have the class be polymorphic
and allow delete through base class ptr. With the "=0" you get both
with only one declaration.

--

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

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 22 Apr 2015 10:53:51 -0500
Raw View
--001a11c33d32d2e2010514522d8b
Content-Type: text/plain; charset=UTF-8

On 22 April 2015 at 10:49, Johannes Schaub <schaub.johannes@googlemail.com>
wrote:

> > Again, why don't protected constructors cover this case?  I'm just not
> > seeing it.
> >
>
> You still need a virtual destructor to have the class be polymorphic
> and allow delete through base class ptr. With the "=0" you get both
> with only one declaration.
>

That just seems like too tiny a use case for something which we can express
today to warrant a language change.
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
2 April 2015 at 10:49, Johannes Schaub <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johannes@googl=
email.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"HOEnZb"><div class=3D"h5">&gt; Again, why don&#39;t protected constru=
ctors cover this case?=C2=A0 I&#39;m just not<br>
&gt; seeing it.<br>
&gt;<br>
<br>
</div></div>You still need a virtual destructor to have the class be polymo=
rphic<br>
and allow delete through base class ptr. With the &quot;=3D0&quot; you get =
both<br>
with only one declaration.<br></blockquote><div><br></div><div>That just se=
ems like too tiny a use case for something which we can express today to wa=
rrant a language change.</div></div>-- <br><div class=3D"gmail_signature">=
=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (8=
47) 691-1404</div>
</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 />

--001a11c33d32d2e2010514522d8b--

.


Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 17:59:52 +0200
Raw View
2015-04-22 17:53 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> On 22 April 2015 at 10:49, Johannes Schaub <schaub.johannes@googlemail.com>
> wrote:
>>
>> > Again, why don't protected constructors cover this case?  I'm just not
>> > seeing it.
>> >
>>
>> You still need a virtual destructor to have the class be polymorphic
>> and allow delete through base class ptr. With the "=0" you get both
>> with only one declaration.
>
>
> That just seems like too tiny a use case for something which we can express
> today to warrant a language change.
>

I don't know. Not having to write

class MyBaseClass {
protected:
   MyBaseClass();
   MyBaseClass(const MyBaseClass&);

public:
   virtual ~MyBaseClass();
};

when you can simply write

class MyBaseClass {
   virtual ~MyBaseClass() = 0;
};

sounds like a nice use case. And in the second way, you also
*actually* get an abstract class, and not just an approximation of it.

--

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

.


Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 18:03:59 +0200
Raw View
2015-04-22 17:53 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> On 22 April 2015 at 10:49, Johannes Schaub <schaub.johannes@googlemail.com>
> wrote:
>>
>> > Again, why don't protected constructors cover this case?  I'm just not
>> > seeing it.
>> >
>>
>> You still need a virtual destructor to have the class be polymorphic
>> and allow delete through base class ptr. With the "=0" you get both
>> with only one declaration.
>
>
> That just seems like too tiny a use case for something which we can express
> today to warrant a language change.

I don't see that a language change is warranted either.

It should also be noted that a major ABI that at least GCC and Clang
use by default put the Vtable of a class into the TU where the first
virtual function was defined in. So if you write "= 0 = default;" on a
virtual destructor, I can see how this increases link time and each
object file size, because you get multiple redundant vtables for the
same class in the .o files of every derived class that calls that
implicitly defined inline destructor.

So I prefer my virtual destructor to be non-inline.

--

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

.


Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 22 Apr 2015 19:10:26 +0300
Raw View
On Wednesday 22 April 2015 17:59:52 Johannes Schaub wrote:
> 2015-04-22 17:53 GMT+02:00 Nevin Liber <nevin@eviloverlord.com>:
> > On 22 April 2015 at 10:49, Johannes Schaub
> > <schaub.johannes@googlemail.com>
> >
> > wrote:
> >> > Again, why don't protected constructors cover this case?  I'm just not
> >> > seeing it.
> >>
> >> You still need a virtual destructor to have the class be polymorphic
> >> and allow delete through base class ptr. With the "=0" you get both
> >> with only one declaration.
> >
> > That just seems like too tiny a use case for something which we can
> > express
> > today to warrant a language change.
>
> I don't know. Not having to write
>
> class MyBaseClass {
> protected:
>    MyBaseClass();
>    MyBaseClass(const MyBaseClass&);
>
> public:
>    virtual ~MyBaseClass();
> };
>
> when you can simply write
>
> class MyBaseClass {
>    virtual ~MyBaseClass() = 0;
> };
>
> sounds like a nice use case. And in the second way, you also
> *actually* get an abstract class, and not just an approximation of it.

I think the original suggestion was to be able to provide an inline body of a
pure virtual function. So the motivating example would be:

  class MyBaseClass {
     virtual ~MyBaseClass() = 0 {}
  };

vs.:

  class MyBaseClass {
     virtual ~MyBaseClass() = 0;
  };

  // Assuming we're defining it in a header, it has to be inline
  inline MyBaseClass::~MyBaseClass() {}

Whether or not the function is a destructor is irrelevant, the benefit here is
simply a more concise code. IMHO, if there isn't a reason to not allow it, it
would be a nice change.

--

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

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 22 Apr 2015 11:12:16 -0500
Raw View
--001a11c3ce14b2a9b00514526f78
Content-Type: text/plain; charset=UTF-8

On 22 April 2015 at 10:59, Johannes Schaub <schaub.johannes@googlemail.com>
wrote:

> I don't know. Not having to write
>
> class MyBaseClass {
> protected:
>    MyBaseClass();
>    MyBaseClass(const MyBaseClass&);
>
> public:
>    virtual ~MyBaseClass();
> };
>

Most non-final polymorphic classes shouldn't have public copy (and don't
forget move) constructors anyway, as it is far too easy to slice the
object.


> when you can simply write
>
> class MyBaseClass {
>    virtual ~MyBaseClass() = 0;
> };
>
> sounds like a nice use case. And in the second way, you also
> *actually* get an abstract class, and not just an approximation of it.
>

What is the difference between an abstract class and an approximation of an
abstract class? Specifically, what can you do with one and not the other?
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
2 April 2015 at 10:59, Johannes Schaub <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johannes@googl=
email.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#3=
9;t know. Not having to write<br>
<br>
class MyBaseClass {<br>
protected:<br>
=C2=A0 =C2=A0MyBaseClass();<br>
=C2=A0 =C2=A0MyBaseClass(const MyBaseClass&amp;);<br>
<br>
public:<br>
=C2=A0 =C2=A0virtual ~MyBaseClass();<br>
};<br></blockquote><div><br></div><div>Most non-final polymorphic classes s=
houldn&#39;t have public copy (and don&#39;t forget move) constructors anyw=
ay, as it is far too easy to slice the object.=C2=A0</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">when you can simply write<br>
<br>
class MyBaseClass {<br>
=C2=A0 =C2=A0virtual ~MyBaseClass() =3D 0;<br>
};<br>
<br>
sounds like a nice use case. And in the second way, you also<br>
*actually* get an abstract class, and not just an approximation of it.<br><=
/blockquote><div><br></div><div>What is the difference between an abstract =
class and an approximation of an abstract class? Specifically, what can you=
 do with one and not the other?</div></div>-- <br><div class=3D"gmail_signa=
ture">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:=
nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 (847) 691-1404</div>
</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 />

--001a11c3ce14b2a9b00514526f78--

.


Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 22 Apr 2015 17:16:26 +0100
Raw View
--001a11c3c1b82eba7c0514527c09
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 22, 2015 at 5:03 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> It should also be noted that a major ABI that at least GCC and Clang
> use by default put the Vtable of a class into the TU where the first
> virtual function was defined in.
>

That is really to the TU where the first *non-inline* virtual function is
defined. In many cases this might be the destructor, but the destructor
could also be provided out of the class definition as an inline function
and yield the same behavior.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Apr 22, 2015 at 5:03 PM, Johannes Schaub <span dir=3D"ltr">&lt;=
<a href=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.=
johannes@googlemail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">It should also be noted that a major ABI that at least GCC and Clang<b=
r>
use by default put the Vtable of a class into the TU where the first<br>
virtual function was defined in.=C2=A0<br></blockquote><div><br>That is rea=
lly to the TU where the first *non-inline* virtual function is defined. In =
many cases this might be the destructor, but the destructor could also be p=
rovided out of the class definition as an inline function and yield the sam=
e behavior.<br><br></div></div></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 />

--001a11c3c1b82eba7c0514527c09--

.


Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 18:19:01 +0200
Raw View
2015-04-22 18:16 GMT+02:00 David Rodr=C3=ADguez Ibeas <dibeas@ieee.org>:
>
>
> On Wed, Apr 22, 2015 at 5:03 PM, Johannes Schaub
> <schaub.johannes@googlemail.com> wrote:
>>
>> It should also be noted that a major ABI that at least GCC and Clang
>> use by default put the Vtable of a class into the TU where the first
>> virtual function was defined in.
>
>
> That is really to the TU where the first *non-inline* virtual function is
> defined. In many cases this might be the destructor, but the destructor
> could also be provided out of the class definition as an inline function =
and
> yield the same behavior.
>

I did see a lot of code in LLVMt/Clang that did put empty destructors
into their cpp file and I thought I read somewhere that this is
because otherwise it would emit duplicate Vtables because the dtor was
the first virtual function. Seems like I did misread?

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

.


Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 22 Apr 2015 17:29:04 +0100
Raw View
--001a11c382d054b6f2051452a90e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No, you read correctly. I am just stating that the proposal (which I don't
think I buy into) would be equivalent to:

class T {
   virtual ~T() =3D 0;
};
inline T::~T() {}

That is different from moving the constructor to the .cpp file that will
more efficiently build (avoid duplicate vtables, avoid removing the
duplicates).

The comment was trying to raise the point that while closely related (avoid
providing all virtual functions inline, where the proposal is helping do
exactly that), it is not strictly equivalent. If the class above had a
different non-pure virtual function that was not defined inline, the vtable
would be generated in the TU that defined that function.

On Wed, Apr 22, 2015 at 5:19 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> 2015-04-22 18:16 GMT+02:00 David Rodr=C3=ADguez Ibeas <dibeas@ieee.org>:
> >
> >
> > On Wed, Apr 22, 2015 at 5:03 PM, Johannes Schaub
> > <schaub.johannes@googlemail.com> wrote:
> >>
> >> It should also be noted that a major ABI that at least GCC and Clang
> >> use by default put the Vtable of a class into the TU where the first
> >> virtual function was defined in.
> >
> >
> > That is really to the TU where the first *non-inline* virtual function =
is
> > defined. In many cases this might be the destructor, but the destructor
> > could also be provided out of the class definition as an inline functio=
n
> and
> > yield the same behavior.
> >
>
> I did see a lot of code in LLVMt/Clang that did put empty destructors
> into their cpp file and I thought I read somewhere that this is
> because otherwise it would emit duplicate Vtables because the dtor was
> the first virtual function. Seems like I did misread?
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">No, you read correctly. I am just stating that the proposa=
l (which I don&#39;t think I buy into) would be equivalent to:<br><br>class=
 T {<br>=C2=A0 =C2=A0virtual ~T() =3D 0;<br>};<br>inline T::~T() {}<br><br>=
That is different from moving the constructor to the .cpp file that will mo=
re efficiently build (avoid duplicate vtables, avoid removing the duplicate=
s). =C2=A0<br><br>The comment was trying to raise the point that while clos=
ely related (avoid providing all virtual functions inline, where the propos=
al is helping do exactly that), it is not strictly equivalent. If the class=
 above had a different non-pure virtual function that was not defined inlin=
e, the vtable would be generated in the TU that defined that function.<br><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr =
22, 2015 at 5:19 PM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johannes@googlem=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=
=3D"HOEnZb"><div class=3D"h5">2015-04-22 18:16 GMT+02:00 David Rodr=C3=ADgu=
ez Ibeas &lt;<a href=3D"mailto:dibeas@ieee.org">dibeas@ieee.org</a>&gt;:<br=
>
&gt;<br>
&gt;<br>
&gt; On Wed, Apr 22, 2015 at 5:03 PM, Johannes Schaub<br>
&gt; &lt;<a href=3D"mailto:schaub.johannes@googlemail.com">schaub.johannes@=
googlemail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; It should also be noted that a major ABI that at least GCC and Cla=
ng<br>
&gt;&gt; use by default put the Vtable of a class into the TU where the fir=
st<br>
&gt;&gt; virtual function was defined in.<br>
&gt;<br>
&gt;<br>
&gt; That is really to the TU where the first *non-inline* virtual function=
 is<br>
&gt; defined. In many cases this might be the destructor, but the destructo=
r<br>
&gt; could also be provided out of the class definition as an inline functi=
on and<br>
&gt; yield the same behavior.<br>
&gt;<br>
<br>
</div></div>I did see a lot of code in LLVMt/Clang that did put empty destr=
uctors<br>
into their cpp file and I thought I read somewhere that this is<br>
because otherwise it would emit duplicate Vtables because the dtor was<br>
the first virtual function. Seems like I did misread?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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 />

--001a11c382d054b6f2051452a90e--

.


Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 22 Apr 2015 13:57:29 -0400
Raw View
--001a11c3f56c9023d0051453e517
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 22, 2015 at 5:55 AM, Columbo <r.hl@gmx.net> wrote:

> Good morning. Is there any technical reason why
>
> virtual void foo() = 0 {};
>
> is not allowed? The grammar can be adjusted, and parsers seem to deal fine
> with it: VC++ even allows this as an extension.
>
> I'd propose to adjust* function-definition* to include *pure-specifier*s.
> Would such a proposal be successful?
>
> --
>
>

I think this is perfectly reasonable (although that may be because I've
used VC++)  - pure virtual is orthogonal to having an implementation.
Tony

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Apr 22, 2015 at 5:55 AM, Columbo <span dir=3D"ltr">&lt;<a href=
=3D"mailto:r.hl@gmx.net" target=3D"_blank">r.hl@gmx.net</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Good morning. Is ther=
e any technical reason why <br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#008">virtual</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> foo</span><span style=3D"color:#660">()</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{};</span><span style=3D=
"color:#000"><br></span></div></code></div><br>is not allowed? The grammar =
can be adjusted, and parsers seem to deal fine with it: VC++ even allows th=
is as an extension.<br><br>I&#39;d propose to adjust<i> function-definition=
</i> to include <i>pure-specifier</i>s. Would such a proposal be successful=
?<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div><sp=
an class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<br></font></span></blockquote><div><br><br></div><div>I think this is perf=
ectly reasonable (although that may be because I&#39;ve used VC++)=C2=A0 - =
pure virtual is orthogonal to having an implementation.<br></div><div>Tony<=
br></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 />

--001a11c3f56c9023d0051453e517--

.


Author: Columbo <r.hl@gmx.net>
Date: Thu, 23 Apr 2015 03:27:59 -0700 (PDT)
Raw View
------=_Part_207_712141927.1429784879451
Content-Type: multipart/alternative;
 boundary="----=_Part_208_1043002358.1429784879451"

------=_Part_208_1043002358.1429784879451
Content-Type: text/plain; charset=UTF-8

Let me get this straight. The only (substantial) difference between
struct A1 { virtual void f(); };
and
struct A2 { virtual void f() = 0; }
is that A2 is *abstract* and derived classes are forced to override and
define f to be able to be a most-derived class - right? However, I can
provide an in-class definition for A1::foo:
struct A1 { virtual void f(){} };
7.1.2/3 specifies that this is equivalent to
struct A1 { virtual void f(); };
inline void A1::f() {}
So this would cause the same problems as
struct A1 { virtual void f() = 0 {}; };
However, for the sake of consistency, even though in-class definitions
might not be optimal - wouldn't it still be feasible to make those
available for pure virtual functions?
Assuredly there is a reason that VC++ allows this?

--

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

<div dir=3D"ltr">Let me get this straight. The only (substantial) differenc=
e between<br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
A1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></div></code></div>and <br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> A2 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div>is that A2 is <i>abstract</i> and derived classes are forced to o=
verride and define f to be able to be a most-derived class - right? However=
, I can provide an in-class definition for A1::foo:<br><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> A1 </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(){}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>7.1.=
2/3 specifies that this is equivalent to<br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> A1 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> A1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div>So this would=
 cause the same problems <code>as</code><code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> A1 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span></div></code></div>However, for the sake of consistency, =
even though in-class definitions might not be optimal - wouldn't it still b=
e feasible to make those available for pure virtual functions?<br>Assuredly=
 there is a reason that VC++ allows this?<br><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 />

------=_Part_208_1043002358.1429784879451--
------=_Part_207_712141927.1429784879451--

.