------=_Part_3196_27099907.1359005940759
Content-Type: text/plain; charset=ISO-8859-1

It's common when working with class hierarchies that you'll want to
describe the object's type in some useful way that can be dynamically
accessed. A good example of this would be reflection where you might want
to store description information for each class. Two obvious approaches for
doing this now would be:

1) Virtual function:
  class Base{ virtual bool IsComposite(){return false}; };
  class Single:public Base{};
  class Multi:public Base{virtual bool IsComposite(){ return true; }};


2) Data member:
  class Base{ bool IsComposite; Base():IsComposite(false){} };
  class Single : public Base{};
  class Multi : public Base{Multi():IsComposite(true){}};


The first approach suffers from virtual function call overhead -- follow
the vtable pointer then follow the function pointer and execute. The second
approach uses unnecessary additional memory to store the bool per object
instance and does not adequately represent that it is a property of the
type.

I'd like to float the idea of virtual data members. A virtual data member
is a static const value that is stored in the class's vtable. 'Virtual'
simply provides a method to access a static const data member according to
the dynamic type of an object. Subclasses can override the *initialization *(but
not the type) of these virtual data members.  This is a middle ground
between the two approaches above, storing only only one value per class
instead of per object.

So in this example we could instead do:
class Base {virtual const bool IsComposite=false;};                 //vtable
contains value false
class Single : public Base{};                                       //vtable
contains value false
class Multi : public Base { virtual const bool IsComposite=true;};  //vtable
contains value true

....
{
Base*b= new Derived;
b->IsComposite; //false

Base*m= new Multi;
m->IsComposite; //true
Base::IsComposite;//false
}


Although the standard doesn't require the existence of a vtable, we can
colloquially expect that the compiler would implement this by simply
inserting the bool into a properly-aligned, well-defined location in the
vtable of Base and each subclass of Base.

The syntax here can be flexible but I think that virtual is a great word to
use. Override and final can map naturally to the same intuitive meaning.
Unfortunately the =0 syntax for pure virtual functions doesn't map over so
nicely here since =0 would likely be understood as the value initializer.
Instead, =delete can be used to mark the data as 'pure virtual'. Classes
with pure virtual data members cannot be instantiated and pure virtual data
members cannot be statically accessed.

Thoughts?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3196_27099907.1359005940759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It's common when working with class hierarchies that you'll want to describ=
e the object's type in some useful way that can be dynamically accessed. A =
good example of this would be reflection where you might want to store desc=
ription information for each class. Two obvious approaches for doing this n=
ow would be:<div><br><div>1) Virtual function:</div><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Base</span><s=
pan 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;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">IsComposite</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(){</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Single</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">public</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Base</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Multi</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bo=
ol</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">IsComposite</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">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">true</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: #660;" class=3D"styled-by-pret=
tify">}};</span></div></code></div><div><br></div><div><br></div><div>2) Da=
ta member:</div><div style=3D"background-color: rgb(250, 250, 250); border:=
 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify">&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Base</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=
">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">IsComposite</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Base</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">():</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">IsComposite</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">false</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-prett=
ify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Single</span><sp=
an 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: #008;" =
class=3D"styled-by-prettify">public</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Base</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{};</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Multi</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">public</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Base</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Multi</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
():</span><span style=3D"color: #606;" class=3D"styled-by-prettify">IsCompo=
site</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">true</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">){}};</span></div></c=
ode></div><div><br></div><div><br></div><div>The first approach suffers fro=
m virtual function call overhead -- follow the vtable pointer then follow t=
he function pointer and execute. The second approach uses unnecessary addit=
ional memory to store the bool per object instance and does not adequately =
represent that it is a property of the type.</div><div><br></div><div>I'd l=
ike to float the idea of virtual data members. A virtual data member is a s=
tatic const value that is stored in the class's vtable. 'Virtual' simply pr=
ovides a method to access a static const data member according to the dynam=
ic type of an object. Subclasses can override the <i>initialization </i>(bu=
t not the type)&nbsp;of these virtual data members. &nbsp;This is a middle =
ground between the two approaches above, storing only only one value per cl=
ass instead of per object.</div><div><br></div><div>So in this example we c=
ould instead do:</div><div style=3D"background-color: rgb(250, 250, 250); b=
order: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=3D"prett=
yprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Base</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: #008;" class=3D"styled-by=
-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">IsComposite</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//vtable contains value false</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Single</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><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">public</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//vtable=
 contains value false</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Multi</sp=
an><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: #0=
08;" class=3D"styled-by-prettify">public</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Base</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">IsComposite</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">true</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//vtable contains value true</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Base</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Derived</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">IsComposite</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//false</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Base</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">m</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Multi</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>m</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color:=
 #606;" class=3D"styled-by-prettify">IsComposite</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: #800;" class=3D"=
styled-by-prettify">//true</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Base</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #606;" class=3D"styled-by-prettify">IsCo=
mposite</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">//false</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code>=
</div><div><br></div><div><br></div><div>Although the standard doesn't requ=
ire the existence of a vtable, we can colloquially expect that the compiler=
 would implement this by simply inserting the bool into a properly-aligned,=
 well-defined location in the vtable of Base and each subclass of Base.</di=
v><div><br></div><div>The syntax here can be flexible but I think that virt=
ual is a great word to use. Override and final can map naturally to the sam=
e intuitive meaning. Unfortunately the =3D0 syntax for pure virtual functio=
ns doesn't map over so nicely here since =3D0 would likely be understood as=
 the value initializer. Instead,&nbsp;=3Ddelete can be used to mark the dat=
a as 'pure virtual'. Classes with pure virtual data members cannot be insta=
ntiated and pure virtual data members cannot be statically accessed.</div><=
div><br>Thoughts?</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3196_27099907.1359005940759--

.

------=_Part_2284_18186806.1359014600871
Content-Type: text/plain; charset=ISO-8859-1

I can't really consider this a problem significant enough to be worth
solving. All it saves is a few cache-line reads on a virtual call, or a
couple of bytes of memory per object that you use in inheritance scenarios.
Is this really something that deserves a language change? Are we really
agonizing over a few bytes of data in inheritance graphs?

It's also not entirely clear what the lifetime of this virtual variable is.
Are literal types the only types allowed, or are user-defined types
allowed? When do they get created, and who is responsible for doing so?
When do they get destroyed?

Also, overloading `= delete` to mean something completely different from
what `= delete` normally means is not going to be acceptable. I would much
rather you either not be allowed to have pure-virtual data members at all,
or force constructor/uniform initialization syntax for them:

virtual int dataMember1(2);
virtual int dataMember2{3};
virtual int dataMember3 = 4; //Not legal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2284_18186806.1359014600871
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I can't really consider this a problem significant enough to be worth=20
solving. All it saves is a few cache-line reads on a virtual call, or a=20
couple of bytes of memory per object that you use in inheritance=20
scenarios. Is this really something that deserves a language change? Are
 we really agonizing over a few bytes of data in inheritance graphs?<br><br=
>It's
 also not entirely clear what the lifetime of this virtual variable is.=20
Are literal types the only types allowed, or are user-defined types=20
allowed? When do they get created, and who is responsible for doing so?=20
When do they get destroyed?<br><br>Also, overloading `=3D delete` to mean=
=20
something completely different from what `=3D delete` normally means is=20
not going to be acceptable. I would much rather you either not be=20
allowed to have pure-virtual data members at all, or force=20
constructor/uniform initialization syntax for them:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><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">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> dataMember1</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">vi=
rtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> dataMember2</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color=
: #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">virtual</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> dataMember3 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</sp=
an><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: #800;" class=3D"styled-by-prettify">//Not legal.</span></div></code>=
</div><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2284_18186806.1359014600871--

.

------=_Part_1833_25611801.1359026125943
Content-Type: text/plain; charset=ISO-8859-1

I would not dismiss this so readily. Clang, for example, would much
appreciate such a feature (if they ever got out of C++03). The fact is that
people roll their own RTTI for speed, and this is usually how it's
implemented, and they do that because they need the absolutely maximum
performance. Giving them even higher performance would seem to be an
appropriate optimization.

As for lifetime and other issues, they are just regular static variables.
The only thing unusual about them is that they happen to be placed in a
special segment of memory. However, this would mean that if you are on a
system with both ROM and RAM, you would not be able to place some vtables
in ROM anymore if a non-literal type was used.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1833_25611801.1359026125943
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would not dismiss this so readily. Clang, for example, would much appreci=
ate such a feature (if they ever got out of C++03). The fact is that people=
 roll their own RTTI for speed, and this is usually how it's implemented, a=
nd they do that because they need the absolutely maximum performance. Givin=
g them even higher performance would seem to be an appropriate optimization=
..<div><br></div><div>As for lifetime and other issues, they are just regula=
r static variables. The only thing unusual about them is that they happen t=
o be placed in a special segment of memory. However, this would mean that i=
f you are on a system with both ROM and RAM, you would not be able to place=
 some vtables in ROM anymore if a non-literal type was used.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1833_25611801.1359026125943--

.

------=_Part_321_25004684.1359043580829
Content-Type: text/plain; charset=ISO-8859-1

That's right - these would have all the same initialization and lifetime
rules as static const variables.

I don't see any reason why we couldn't allow user-defined types since it
follows the same basic rules as static const. The RAM/ROM issue is
interesting for platforms that support it. I believe this can be accounted
for by the compiler. If you need to guarantee that the vtable is placed in
ROM then declaring the data member as constexpr e.g. 'virtual constexpr
MyType(1);' should be sufficient to support that guarantee. The compiler
can have its own switches for e.g. raising a warning or error if a vtable
cannot be placed in ROM.

I do see this as a valuable problem worth solving.Rarely is it actually a
feasible solution to store type information directly in the object because
that will significantly bloat structure size beyond some trivial amount of
data.  Any non-trivial implementation of roll-your-own type information is
often going to require a per-object pointer to some class object which is
basically what the vtable pointer already exists for. Allowing us to stuff
additional data in this existing structure would be great for cache
locality since some portion of the vtable would often already be in memory.

Consider the existing solution one might implement where each object stores
a pointer-to-type-info. I know this is a common implementation in many
object frameworks. By moving to virtual data you would have the advantage
of no longer needing this per-object pointer-to-type and have improved
chances that the data you want will already be cached. The disadvantage is
that the type info you store would now need to be static const.

The advantage over virtual function calls is instruction cache locality and
saving the overhead of a function call. Function call overhead can be
significant in tight loops especially since these calls cannot in general
be inlined. The compiler knows that simply accessing this data cannot
modify global state like a virtual function could and so may present
significant opportunities for optimization in the surrounding code where
virtual functions are converted to virtual data.  The disadvantage is again
static const.

The advantage over storing the data in the object is an reduction in
per-object memory usage which may help with cache locality. The
disadvantage is the static const requirement and the single indirection to
get at the data.

For cases where you do indeed have static const/constexpr data that you
want associated with a type, virtual data members could be a very useful
tool for improving performance and making good guarantees about your type.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_321_25004684.1359043580829
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>That's right - these would have all the same initialization and lifeti=
me rules as static const variables.</div><div><br></div><div>I don't see an=
y reason why we couldn't allow user-defined types since it follows the same=
 basic rules as static const. The RAM/ROM issue is interesting for platform=
s that support it. I believe this can be accounted for by the compiler. If =
you need to guarantee that the vtable is placed in ROM then declaring the d=
ata member as constexpr e.g. 'virtual constexpr MyType(1);' should be suffi=
cient to support that guarantee. The compiler can have its own switches for=
 e.g. raising a warning or error if a vtable cannot be placed in ROM.</div>=
<div><br></div><div>I do see this as a valuable problem worth solving.Rarel=
y is it actually a feasible solution to store type information directly in =
the object because that will significantly bloat structure size beyond some=
 trivial amount of data. &nbsp;Any non-trivial implementation of roll-your-=
own type information is often going to require a per-object pointer to some=
 class object which is basically what the vtable pointer already exists for=
.. Allowing us to stuff additional data in this existing structure would be =
great for cache locality since some portion of the vtable would often alrea=
dy be in memory.&nbsp;</div><div><br></div><div>Consider the existing solut=
ion one might implement where each object stores a pointer-to-type-info. I =
know this is a common implementation in many object frameworks. By moving t=
o virtual data you would have the advantage of no longer needing this per-o=
bject pointer-to-type and have improved chances that the data you want will=
 already be cached. The disadvantage is that the type info you store would =
now need to be static const.<br></div><div><br></div><div>The advantage ove=
r virtual function calls is instruction cache locality and saving the overh=
ead of a function call. Function call overhead can be significant in tight =
loops especially since these calls cannot in general be inlined. The compil=
er knows that simply accessing this data cannot modify global state like a =
virtual function could and so may present significant opportunities for opt=
imization in the surrounding code where virtual functions are converted to =
virtual data. &nbsp;The disadvantage is again static const.</div><div><br><=
/div><div>The advantage over storing the data in the object is an reduction=
 in per-object memory usage which may help with cache locality. The disadva=
ntage is the static const requirement and the single indirection to get at =
the data.</div><div><br></div><div>For cases where you do indeed have stati=
c const/constexpr data that you want associated with a type, virtual data m=
embers could be a very useful tool for improving performance and making goo=
d guarantees about your type.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_321_25004684.1359043580829--

.

------=_Part_140_27853433.1359043762563
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 24, 2013 12:15:25 PM UTC+1, DeadMG wrote:
>
> The fact is that people roll their own RTTI for speed, and this is usually
> how it's implemented, and they do that because they need the absolutely
> maximum performance.


Be that as it may, I think it's more productive to actually extend /
implement the RTTI and introspective capabilities of C++. This proposal
basically suggests a specialization of attributes - some extra properties
stored alongside the type. There is really no reason why it should be
limited to classes. Just look at the possibilities of attributes in other
languages such as Java and .Net.

So a -1 for this proposal for me. But if it will be considered, a couple of
points:
- I don't like the term "virtual data members", nor the syntax. It suggests
instance members, while they're really static. I think "virtual static int
member" would be better syntax.
- Why are they being initialized in the constructor? Do I really need to
construct an instance for them to be initialized? And can the
initialization depend on constructor parameters? If they're static, at
least treat them the same as other static members.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_140_27853433.1359043762563
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, January 24, 2013 12:15:25 PM UTC+1, DeadMG wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">The fact is that people roll their =
own RTTI for speed, and this is usually how it's implemented, and they do t=
hat because they need the absolutely maximum performance.</blockquote><div>=
<br></div><div>Be that as it may, I think it's more productive to actually =
extend / implement the RTTI and introspective capabilities of C++. This pro=
posal basically suggests a specialization of attributes - some extra proper=
ties stored alongside the type. There is really no reason why it should be =
limited to classes. Just look at the possibilities of attributes in other l=
anguages such as Java and .Net.</div><div><br></div><div>So a -1 for this p=
roposal for me. But if it will be considered, a couple of points:</div><div=
>- I don't like the term "virtual data members", nor the syntax. It suggest=
s instance members, while they're really static. I think "virtual static in=
t member" would be better syntax.</div><div>- Why are they being initialize=
d in the constructor? Do I really need to construct an instance for them to=
 be initialized? And can the initialization depend on constructor parameter=
s? If they're static, at least treat them the same as other static members.=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_140_27853433.1359043762563--

.

------=_Part_1027_31432350.1359044342214
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, January 24, 2013 10:09:22 AM UTC-6, Sylvester Hesp wrote:

> - Why are they being initialized in the constructor? Do I really need to
> construct an instance for them to be initialized? And can the
> initialization depend on constructor parameters? If they're static, at
> least treat them the same as other static members.
>

 My examples above are initializing them exactly the same as static const
member data would be initialized, not in the constructor. The
initialization would occur during static initialization like normal static
data members.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1027_31432350.1359044342214
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, January 24, 2013 10:09:22 AM UTC-6, Sylvester Hesp wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">- Why are they being initialize=
d in the constructor? Do I really need to construct an instance for them to=
 be initialized? And can the initialization depend on constructor parameter=
s? If they're static, at least treat them the same as other static members.=
<br></blockquote><div><br></div><div>&nbsp;My examples above are initializi=
ng them exactly the same as static const member data would be initialized, =
not in the constructor. The initialization would occur during static initia=
lization like normal static data members.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1027_31432350.1359044342214--

.

------=_Part_1976_24783343.1359045952955
Content-Type: text/plain; charset=ISO-8859-1

Extending the introspective capacity of C++ wouldn't solve the same
problem. We already have the capacity to get this kind of value- the
problem is that the native implementation is too slow for a number of
reasons. Reflection and this proposal do not solve the same problem.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1976_24783343.1359045952955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Extending the introspective capacity of C++ wouldn't solve the same problem=
.. We already have the capacity to get this kind of value- the problem is th=
at the native implementation is too slow for a number of reasons. Reflectio=
n and this proposal do not solve the same problem.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1976_24783343.1359045952955--

.

------=_Part_5_17868431.1359059328569
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, January 24, 2013 8:45:52 AM UTC-8, DeadMG wrote:
>
> Extending the introspective capacity of C++ wouldn't solve the same
> problem. We already have the capacity to get this kind of value- the
> problem is that the native implementation is too slow for a number of
> reasons.


Isn't that a problem that should be solved by the implementations? I mean,
this all sounds like a catch-22: the implementors have no pressure to
improve RTTI performance because people don't rely on its performance. And
people don't rely on RTTI performance because implementors don't make it a
priority.

How would that change with this new feature? Is there something about the
current RTTI definition that makes reasonable performance impossible? If
so, isn't *that* what we should fix, rather than promoting hack "solutions"?

Reflection and this proposal do not solve the same problem.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_5_17868431.1359059328569
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, January 24, 2013 8:45:52 AM UTC-8, DeadMG wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Extending the introspective capacity of C++ =
wouldn't solve the same problem. We already have the capacity to get this k=
ind of value- the problem is that the native implementation is too slow for=
 a number of reasons.</blockquote><div><br>Isn't that a problem that should=
 be solved by the implementations? I mean, this all sounds like a catch-22:=
 the implementors have no pressure to improve RTTI performance because peop=
le don't rely on its performance. And people don't rely on RTTI performance=
 because implementors don't make it a priority.<br><br>How would that chang=
e with this new feature? Is there something about the current RTTI definiti=
on that makes reasonable performance impossible? If so, isn't <i>that</i> w=
hat we should fix, rather than promoting hack "solutions"?<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"> Reflection and this proposal do =
not solve the same problem.</blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5_17868431.1359059328569--

.

------=_Part_22_20815125.1359062444347
Content-Type: text/plain; charset=ISO-8859-1

Last I checked, changing the language so that the current RTTI can be
performance-competitive would effectively result in modules, or possibly
something even more extreme in terms of changing the language- i.e., it's
effectively an unfixable problem. The reason why the existing RTTI is so
slow is basically because all inheritance hierarchies are arbitrarily
complex, from the point of view of the runtime, whereas Clang can do
something much cheaper, since it knows that, say, nobody inherits from
llvm::Function- whereas the compiler does not know such a thing.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_22_20815125.1359062444347
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Last I checked, changing the language so that the current RTTI can be perfo=
rmance-competitive would effectively result in modules, or possibly somethi=
ng even more extreme in terms of changing the language- i.e., it's effectiv=
ely an unfixable problem. The reason why the existing RTTI is so slow is ba=
sically because all inheritance hierarchies are arbitrarily complex, from t=
he point of view of the runtime, whereas Clang can do something much cheape=
r, since it knows that, say, nobody inherits from llvm::Function- whereas t=
he compiler does not know such a thing.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_22_20815125.1359062444347--

.

--047d7bd91a729a3cbc04d40f71af
Content-Type: text/plain; charset=ISO-8859-1

On 24 January 2013 15:20, DeadMG <wolfeinstein@gmail.com> wrote:

> Last I checked, changing the language so that the current RTTI can be
> performance-competitive would effectively result in modules, or possibly
> something even more extreme in terms of changing the language- i.e., it's
> effectively an unfixable problem. The reason why the existing RTTI is so
> slow is basically because all inheritance hierarchies are arbitrarily
> complex, from the point of view of the runtime, whereas Clang can do
> something much cheaper, since it knows that, say, nobody inherits from
> llvm::Function- whereas the compiler does not know such a thing.
>

Even with final (not that I'm a fan of final, as it inhibits inheritance
for the sake of morphing the interface)?
--
 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 post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7bd91a729a3cbc04d40f71af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 January 2013 15:20, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailto:wo=
lfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;</spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Last I checked, changing the language so that the current RTTI can be perfo=
rmance-competitive would effectively result in modules, or possibly somethi=
ng even more extreme in terms of changing the language- i.e., it&#39;s effe=
ctively an unfixable problem. The reason why the existing RTTI is so slow i=
s basically because all inheritance hierarchies are arbitrarily complex, fr=
om the point of view of the runtime, whereas Clang can do something much ch=
eaper, since it knows that, say, nobody inherits from llvm::Function- where=
as the compiler does not know such a thing.<br>

</blockquote><div><br>Even with final (not that I&#39;m a fan of final, as =
it inhibits inheritance for the sake of morphing the interface)? <br></div>=
</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bd91a729a3cbc04d40f71af--

.

On 1/24/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> I can't really consider this a problem significant enough to be worth
> solving. All it saves is a few cache-line reads on a virtual call, or a
> couple of bytes of memory per object that you use in inheritance scenarios.

Some objects are instantiated enough so that a couple of bytes per
object could be large amounts of memory.

Likewise, a few cache-line reads could turn into a few cache-line
misses, which could turn into hundreds of cycles.

If we can reliably move a significant amount of static information
into the virtual tables, we should consider it.  However, it is not
clear to me from the description that we have the evidence yet.
Is there an application in which such a feature would have made
a difference?

>
> Is this really something that deserves a language change? Are we really
> agonizing over a few bytes of data in inheritance graphs?
>
> It's also not entirely clear what the lifetime of this virtual variable is.
>
> Are literal types the only types allowed, or are user-defined types
> allowed? When do they get created, and who is responsible for doing so?
> When do they get destroyed?
>
> Also, overloading `= delete` to mean something completely different from
> what `= delete` normally means is not going to be acceptable. I would much
> rather you either not be allowed to have pure-virtual data members at all,
> or force constructor/uniform initialization syntax for them:
>
> virtual int dataMember1(2);
> virtual int dataMember2{3};
> virtual int dataMember3 = 4; //Not legal.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to
> std-proposals+unsubscribe@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>


--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_44_27463724.1359064343294
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, January 24, 2013 10:20:44 PM UTC+1, DeadMG wrote:

> Last I checked, changing the language so that the current RTTI can be
> performance-competitive would effectively result in modules, or possibly
> something even more extreme in terms of changing the language- i.e., it's
> effectively an unfixable problem. The reason why the existing RTTI is so
> slow is basically because all inheritance hierarchies are arbitrarily
> complex, from the point of view of the runtime, whereas Clang can do
> something much cheaper, since it knows that, say, nobody inherits from
> llvm::Function- whereas the compiler does not know such a thing.


We're not dealing with inheritance structures. What's slow is dynamic_cast,
not typeid. The latter typically takes the typeinfo usually right out of
the vtable (well it's somewhat more complicated than that as it needs to
work with non-vtable objects as well, but it's still constant time
complexity). Exposing class attributes in a similar way could have
*exactly* the same performance as is suggested by this proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_44_27463724.1359064343294
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, January 24, 2013 10:20:44 PM UTC+1, DeadMG wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">Last I checked, changing the language s=
o that the current RTTI can be performance-competitive would effectively re=
sult in modules, or possibly something even more extreme in terms of changi=
ng the language- i.e., it's effectively an unfixable problem. The reason wh=
y the existing RTTI is so slow is basically because all inheritance hierarc=
hies are arbitrarily complex, from the point of view of the runtime, wherea=
s Clang can do something much cheaper, since it knows that, say, nobody inh=
erits from llvm::Function- whereas the compiler does not know such a thing.=
</blockquote><div><br></div><div>We're not dealing with inheritance structu=
res. What's slow is dynamic_cast, not typeid. The latter typically takes th=
e typeinfo usually right out of the vtable (well it's somewhat more complic=
ated than that as it needs to work with non-vtable objects as well, but it'=
s still constant time complexity). Exposing class attributes in a similar w=
ay could have *exactly* the same performance as is suggested by this propos=
al.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_44_27463724.1359064343294--

.

------=_Part_184_24054970.1359080263579
Content-Type: text/plain; charset=ISO-8859-1

The concern with respect to overlapping functionality with attributes is
valid, but I'm not sure that they could have the same performance as you
suggest.

Suppose class Base has no attributes. Class Derived : public Base has
attribute [[special]]. Given a Base pointer I want to know if it is
[[special]]. Given that there are an arbitrary number of user-defined
attributes so we can't store them all for every class -- how could this
lookup be done without say a hash table?

Additionally, it may be possible to drop the requirement that virtual data
be const. If that requirement were dropped then it opens up a lot of
possibilities that attributes could not handle. If the value was non-const
then you could use it to store e.g. number of objects currently
instantiated, or the head of an intrusive linked list of all objects of
this type. I'm not sure if non-const data could be placed in the vtable
which is why I didn't originally include it. But if it can be allowed it
would significantly strengthen the value this offers.

--

---
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/?hl=en.



------=_Part_184_24054970.1359080263579
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The concern with respect to overlapping functionality with attributes is va=
lid, but I'm not sure that they could have the same performance as you sugg=
est.<div><br></div><div>Suppose class Base has no attributes. Class Derived=
 : public Base has attribute [[special]]. Given a Base pointer I want to kn=
ow if it is [[special]]. Given that there are an arbitrary number of user-d=
efined attributes so we can't store them all for every class -- how could t=
his lookup be done without say a hash table?</div><div><br></div><div>Addit=
ionally, it may be possible to drop the requirement that virtual data be co=
nst. If that requirement were dropped then it opens up a lot of possibiliti=
es that attributes could not handle. If the value was non-const then you co=
uld use it to store e.g. number of objects currently instantiated, or the h=
ead of an intrusive linked list of all objects of this type. I'm not sure i=
f non-const data could be placed in the vtable which is why I didn't origin=
ally include it. But if it can be allowed it would significantly strengthen=
 the value this offers.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_184_24054970.1359080263579--

.

------=_Part_67_22892316.1359080498253
Content-Type: text/plain; charset=ISO-8859-1

As for RAM/ROM, one could conceivably create two tables, place one in ROM,
as the regular vtable, and simply add a pointer to another table in RAM for
non-const members.

--

---
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/?hl=en.



------=_Part_67_22892316.1359080498253
Content-Type: text/html; charset=ISO-8859-1

As for RAM/ROM, one could conceivably create two tables, place one in ROM, as the regular vtable, and simply add a pointer to another table in RAM for non-const members. 

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_67_22892316.1359080498253--

.

------=_Part_228_23469756.1359081521676
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 24, 2013 1:52:23 PM UTC-8, Sylvester Hesp wrote:
>
> On Thursday, January 24, 2013 10:20:44 PM UTC+1, DeadMG wrote:
>
>> Last I checked, changing the language so that the current RTTI can be
>> performance-competitive would effectively result in modules, or possibly
>> something even more extreme in terms of changing the language- i.e., it's
>> effectively an unfixable problem. The reason why the existing RTTI is so
>> slow is basically because all inheritance hierarchies are arbitrarily
>> complex, from the point of view of the runtime, whereas Clang can do
>> something much cheaper, since it knows that, say, nobody inherits from
>> llvm::Function- whereas the compiler does not know such a thing.
>
>
> We're not dealing with inheritance structures. What's slow is
> dynamic_cast, not typeid.
>

OK, but before we solve a problem, let's analyze why dynamic_cast is slow
to begin with. What exactly is it about this feature that [i]requires[/i]
that it be slow, and why would this "virtual data" be somehow faster? Isn't
there a way to implement dynamic_cast so that it could just automatically
generate and use this data?

--

---
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/?hl=en.



------=_Part_228_23469756.1359081521676
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, January 24, 2013 1:52:23 PM UTC-8, Sylvester Hesp wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, January 24, 201=
3 10:20:44 PM UTC+1, DeadMG wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">Last I checked, changing the language so that the current RTTI can be pe=
rformance-competitive would effectively result in modules, or possibly some=
thing even more extreme in terms of changing the language- i.e., it's effec=
tively an unfixable problem. The reason why the existing RTTI is so slow is=
 basically because all inheritance hierarchies are arbitrarily complex, fro=
m the point of view of the runtime, whereas Clang can do something much che=
aper, since it knows that, say, nobody inherits from llvm::Function- wherea=
s the compiler does not know such a thing.</blockquote><div><br></div><div>=
We're not dealing with inheritance structures. What's slow is dynamic_cast,=
 not typeid.</div></blockquote><div><br>OK, but before we solve a problem, =
let's analyze why dynamic_cast is slow to begin with. What exactly is it ab=
out this feature that [i]requires[/i] that it be slow, and why would this "=
virtual data" be somehow faster? Isn't there a way to implement dynamic_cas=
t so that it could just automatically generate and use this data?</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_228_23469756.1359081521676--

.

------=_Part_75_13308161.1359082296655
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, January 24, 2013 8:38:41 PM UTC-6, Nicol Bolas wrote:

>
> OK, but before we solve a problem, let's analyze why dynamic_cast is slow
> to begin with. What exactly is it about this feature that [i]requires[/i]
> that it be slow, and why would this "virtual data" be somehow faster? Isn't
> there a way to implement dynamic_cast so that it could just automatically
> generate and use this data?
>

Dynamic cast does not solve the problems that I'm attempting to solve here.
A dynamic cast allows you to ask if object a is of type b. I want to
retrieve property c on the type of object a regardless of what that type
is. This question cannot be answered with RTTI.

--

---
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/?hl=en.



------=_Part_75_13308161.1359082296655
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, January 24, 2013 8:38:41 PM UTC-6, Nicol Bolas wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><br><div>OK, but before we solve a =
problem, let's analyze why dynamic_cast is slow to begin with. What exactly=
 is it about this feature that [i]requires[/i] that it be slow, and why wou=
ld this "virtual data" be somehow faster? Isn't there a way to implement dy=
namic_cast so that it could just automatically generate and use this data?<=
/div></blockquote><div><br></div><div>Dynamic cast does not solve the probl=
ems that I'm attempting to solve here. A dynamic cast allows you to ask if =
object a is of type b. I want to retrieve property c on the type of object =
a regardless of what that type is. This question cannot be answered with RT=
TI.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_75_13308161.1359082296655--

.

------=_Part_237_26225314.1359085839671
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Great proposal!  For quite some time I have been dreaming of such a feature!

One more thing, could it be named "virtual static" instead of "virtual
const", and allow modification of the variable / support "virtual static"
functions?

Such feature is necessary in some cases when you are using GC.  The example
below is a code snippet of a GC'ed object class and a derivation of the
object class with shared information (that needs to be freed once  all
instances of the derived type are being collected).

Under the current C++ spec, we need to do a virtual call for every single
sweep.

struct GCObject {
  virtual ~GCObject() {}
};


struct Derived : public GCObject {
  static size_t numObjectsOfType_;
  static SharedInfo* shared_;
  Derived() {
    if (numObjectsOfType_++ == 0)
      shared_ = newSharedInfo();
    ...
  }
  virtual ~Derived() {
    if (--numObjectsOfType_ == 0)
     delete shared_;
  }
};


void sweepObject(GCObject* o) {
  o->~GCObject();
}

But once "virtual static" variables and functions are introduced, the
overhead of the virtual function call can be omitted by writing code like:

struct GCObject {
  virtual static size_t numObjectsOfType_;
  virtual static void freeShared() {}
  ~GCObject() {} // non-virtual
};


struct Derived : public GCObject {
  static ShareInfo* shared_;
  virtual static freeShared() {
    delete shared_;
  }
  Derived() : GCObject() {
    if (numObjectsOfType_++ == 0)
      shared_ = newSharedInfo();
  }
};


void sweepObject(GCObject* o) {
  if (--o->numObjectsOfType_ == 0)
    o->freeShared();
}

The example might not be good enough to illustrate the necessity of
non-const virtual static variables (since in the example, shared info could
be collected using GC as well instead of using refcounting), but I wanted
to bring my question onto the table; why can't non-const variables be
stored in vtbl?

On Thursday, January 24, 2013 2:39:00 PM UTC+9, Brent Friedman wrote:

> It's common when working with class hierarchies that you'll want to
> describe the object's type in some useful way that can be dynamically
> accessed. A good example of this would be reflection where you might want
> to store description information for each class. Two obvious approaches for
> doing this now would be:
>
> 1) Virtual function:
>   class Base{ virtual bool IsComposite(){return false}; };
>   class Single:public Base{};
>   class Multi:public Base{virtual bool IsComposite(){ return true; }};
>
>
> 2) Data member:
>   class Base{ bool IsComposite; Base():IsComposite(false){} };
>   class Single : public Base{};
>   class Multi : public Base{Multi():IsComposite(true){}};
>
>
> The first approach suffers from virtual function call overhead -- follow
> the vtable pointer then follow the function pointer and execute. The second
> approach uses unnecessary additional memory to store the bool per object
> instance and does not adequately represent that it is a property of the
> type.
>
> I'd like to float the idea of virtual data members. A virtual data member
> is a static const value that is stored in the class's vtable. 'Virtual'
> simply provides a method to access a static const data member according to
> the dynamic type of an object. Subclasses can override the *initialization
> *(but not the type) of these virtual data members.  This is a middle
> ground between the two approaches above, storing only only one value per
> class instead of per object.
>
> So in this example we could instead do:
> class Base {virtual const bool IsComposite=false;};                 //vtable
> contains value false
> class Single : public Base{};                                       //vtable
> contains value false
> class Multi : public Base { virtual const bool IsComposite=true;};  //vtable
> contains value true
>
> ...
> {
> Base*b= new Derived;
> b->IsComposite; //false
>
> Base*m= new Multi;
> m->IsComposite; //true
> Base::IsComposite;//false
> }
>
>
> Although the standard doesn't require the existence of a vtable, we can
> colloquially expect that the compiler would implement this by simply
> inserting the bool into a properly-aligned, well-defined location in the
> vtable of Base and each subclass of Base.
>
> The syntax here can be flexible but I think that virtual is a great word
> to use. Override and final can map naturally to the same intuitive meaning.
> Unfortunately the =0 syntax for pure virtual functions doesn't map over so
> nicely here since =0 would likely be understood as the value initializer.
> Instead, =delete can be used to mark the data as 'pure virtual'. Classes
> with pure virtual data members cannot be instantiated and pure virtual data
> members cannot be statically accessed.
>
> Thoughts?
>

--

---
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/?hl=en.



------=_Part_237_26225314.1359085839671
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Great proposal! &nbsp;For quite some time I have bee=
n dreaming of such a feature!<br><br>One more thing, could it be named "vir=
tual static" instead of "virtual const", and allow modification of the vari=
able / support "virtual static" functions?</div><div><br></div><div>Such fe=
ature is necessary in some cases when you are using GC. &nbsp;The example b=
elow is a code snippet of a GC'ed object class and a derivation of the obje=
ct class with shared information (that needs to be freed once &nbsp;all ins=
tances of the derived type are being collected).</div><div><br></div><div>U=
nder the current C++ spec, we need to do a virtual call for every single sw=
eep.</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250)=
; border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">GCObject</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"><br>&nbsp; </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">~</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
GCObject</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Derived</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">public=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">GCObject</span><spa=
n 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"><br>&nbsp; </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">static</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> size_t numObjectsOfType_</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">static</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">SharedInfo</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> shared_</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Derived</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><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><s=
pan 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">numObjectsOfType_</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp; &nbsp; &nbsp; shared_ </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> newSharedInfo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">~<=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Derived</sp=
an><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">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(--</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">numObjectsOfType_ </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; &nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">delete</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> shared_</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> sweepObject</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">GCObject</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> o</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt=
;~</span><span style=3D"color: #606;" class=3D"styled-by-prettify">GCObject=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><d=
iv><br>But once "virtual static" variables and functions are introduced, th=
e overhead of the virtual function call can be omitted by writing code like=
:</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250); b=
order: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"pret=
typrint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">GCObject</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">static</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> size_t numObjectsOfType_</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
atic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> freeShared</span><sp=
an 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">{}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">~</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">GCObject</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </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: #800;" class=3D"styled-by-prettify">// non-vir=
tual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Derived</span><span style=3D"co=
lor: #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: #008;" class=3D"style=
d-by-prettify">public</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">GCObject</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"><br>&nbsp; </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">static</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">ShareInfo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> shared_</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> freeShared</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">delet=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> shared_<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Derived</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #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: #606;" class=3D"styled-b=
y-prettify">GCObject</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">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp=
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">numObjectsOfType_</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp; &nbsp; shared_ </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> newSharedInfo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sweepObject=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">GCObject</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> o</span><span style=3D"colo=
r: #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">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(--<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">o</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">numObjectsOfType_ </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=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=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; o</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">freeShared</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><div><br>The example might not be =
good enough to illustrate the necessity of non-const virtual static variabl=
es (since in the example, shared info could be collected using GC as well i=
nstead of using refcounting), but I wanted to bring my question onto the ta=
ble; why can't non-const variables be stored in vtbl?</div><div><br></div><=
div>On Thursday, January 24, 2013 2:39:00 PM UTC+9, Brent Friedman wrote:<b=
r></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It's common when =
working with class hierarchies that you'll want to describe the object's ty=
pe in some useful way that can be dynamically accessed. A good example of t=
his would be reflection where you might want to store description informati=
on for each class. Two obvious approaches for doing this now would be:<div>=
<br><div>1) Virtual function:</div><div style=3D"background-color:rgb(250,2=
50,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div>=
<span style=3D"color:#000">&nbsp; </span><span style=3D"color:#008">class</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base</sp=
an><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">virtual</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">bool</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">IsComposite</span><span style=3D"color:#660">(){</s=
pan><span style=3D"color:#008">return</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">false</span><span style=3D"color:#660">};</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">};</span>=
<span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">cla=
ss</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Sing=
le</span><span style=3D"color:#660">:</span><span style=3D"color:#008">publ=
ic</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base=
</span><span style=3D"color:#660">{};</span><span style=3D"color:#000"><br>=
&nbsp; </span><span style=3D"color:#008">class</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Multi</span><span style=3D"color:#6=
60">:</span><span style=3D"color:#008">public</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">Base</span><span style=3D"color:#660=
">{</span><span style=3D"color:#008">virtual</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">bool</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">IsComposite</span><span style=3D"color:=
#660">(){</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">true</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">}};</span></div></code></div><div><br><=
/div><div><br></div><div>2) Data member:</div><div style=3D"background-colo=
r:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word">=
<code><div><span style=3D"color:#000">&nbsp; </span><span style=3D"color:#0=
08">class</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">Base</span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">IsComposite</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"> </span><span style=3D"color:#606">B=
ase</span><span style=3D"color:#660">():</span><span style=3D"color:#606">I=
sComposite</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
08">false</span><span style=3D"color:#660">){}</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#000"=
><br>&nbsp; </span><span style=3D"color:#008">class</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#606">Single</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">:</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">public</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Base</span><span style=3D"color:#66=
0">{};</span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"co=
lor:#008">class</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">Multi</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">:</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">public</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">Base</span><span style=3D"color:#660">{</span><span style=3D"color:#606"=
>Multi</span><span style=3D"color:#660">():</span><span style=3D"color:#606=
">IsComposite</span><span style=3D"color:#660">(</span><span style=3D"color=
:#008">true</span><span style=3D"color:#660">)<wbr>{}};</span></div></code>=
</div><div><br></div><div><br></div><div>The first approach suffers from vi=
rtual function call overhead -- follow the vtable pointer then follow the f=
unction pointer and execute. The second approach uses unnecessary additiona=
l memory to store the bool per object instance and does not adequately repr=
esent that it is a property of the type.</div><div><br></div><div>I'd like =
to float the idea of virtual data members. A virtual data member is a stati=
c const value that is stored in the class's vtable. 'Virtual' simply provid=
es a method to access a static const data member according to the dynamic t=
ype of an object. Subclasses can override the <i>initialization </i>(but no=
t the type)&nbsp;of these virtual data members. &nbsp;This is a middle grou=
nd between the two approaches above, storing only only one value per class =
instead of per object.</div><div><br></div><div>So in this example we could=
 instead do:</div><div style=3D"background-color:rgb(250,250,250);border:1p=
x solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"co=
lor:#008">class</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">Base</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">{</span><span style=3D"color:#008">virtual</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">bool</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">IsComposite</span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#008">false</span><span style=3D"c=
olor:#660">;};</span><span style=3D"color:#000"> &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:#800">//vtable co=
ntains value false</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Single</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">:</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">public</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">Base</span><span style=3D"color:#660">{};</span><span style=3D"c=
olor:#000"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </spa=
n><span style=3D"color:#800">//vtable contains value false</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">class</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">Multi</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">:</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">public</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">Base</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">virtual</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">const</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">bool</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">IsComposite</span><span style=3D"col=
or:#660">=3D</span><span style=3D"color:#008">true</span><span style=3D"col=
or:#660">;};</span><span style=3D"color:#000"> &nbsp;</span><span style=3D"=
color:#800">//vtable contains value true</span><span style=3D"color:#000"><=
br><br></span><span style=3D"color:#660">...</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#606">Base</span><span style=3D"color:#660=
">*</span><span style=3D"color:#000">b</span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">new</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">Derived</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>b</s=
pan><span style=3D"color:#660">-&gt;</span><span style=3D"color:#606">IsCom=
posite</span><span style=3D"color:#660">;</span><span style=3D"color:#000">=
 </span><span style=3D"color:#800">//false</span><span style=3D"color:#000"=
><br><br></span><span style=3D"color:#606">Base</span><span style=3D"color:=
#660">*</span><span style=3D"color:#000">m</span><span style=3D"color:#660"=
>=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008">ne=
w</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Multi=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>m<=
/span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#606">IsC=
omposite</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#800">//true</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#606">Base</span><span style=3D"color:#66=
0">::</span><span style=3D"color:#606">IsComposite</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#800">//false</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#660">}</span></div></code></div>=
<div><br></div><div><br></div><div>Although the standard doesn't require th=
e existence of a vtable, we can colloquially expect that the compiler would=
 implement this by simply inserting the bool into a properly-aligned, well-=
defined location in the vtable of Base and each subclass of Base.</div><div=
><br></div><div>The syntax here can be flexible but I think that virtual is=
 a great word to use. Override and final can map naturally to the same intu=
itive meaning. Unfortunately the =3D0 syntax for pure virtual functions doe=
sn't map over so nicely here since =3D0 would likely be understood as the v=
alue initializer. Instead,&nbsp;=3Ddelete can be used to mark the data as '=
pure virtual'. Classes with pure virtual data members cannot be instantiate=
d and pure virtual data members cannot be statically accessed.</div><div><b=
r>Thoughts?</div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_237_26225314.1359085839671--

.

------=_Part_275_19014559.1359089333743
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 24, 2013 at 9:50 PM,  <kazuhooku@gmail.com> wrote:
 why can't non-const variables be stored in vtbl?

If it's feasible for the compiler to support then I'd love to drop the
const restriction and just make this a storage class specifier with no
additional requirements.

And I'm quite okay with making the syntax be 'virtual static' or 'static
virtual' since that is just a bit more clear, but it's a bit odd because it
combines two storage class specifiers that are mutually exclusive in other
contexts.

--

---
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/?hl=en.



------=_Part_275_19014559.1359089333743
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 24, 2013 at 9:50 PM, &nbsp;&lt;kazuhooku@gmail.com&gt; wrote:<b=
r><div>&nbsp;why can't non-const variables be stored in vtbl?</div><div><br=
></div><div>If it's feasible for the compiler to support then I'd love to d=
rop the const restriction and just make this a storage class specifier with=
 no additional requirements.</div><div><br></div><div>And I'm quite okay wi=
th making the syntax be 'virtual static' or 'static virtual' since that is =
just a bit more clear, but it's a bit odd because it combines two storage c=
lass specifiers that are mutually exclusive in other contexts.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_275_19014559.1359089333743--

.

------=_Part_276_12786899.1359090190265
Content-Type: text/plain; charset=ISO-8859-1



>   virtual static freeShared() {
>     delete shared_;
>   }
>

I'm only proposing virtual static data members here, not virtual static*functions
*. Unless this was just a mistake, I'm not sure what a virtual static
function is supposed to mean here. From your code it looks like it would
suffice just as a normal static function.

--

---
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/?hl=en.



------=_Part_276_12786899.1359090190265
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"background-c=
olor:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-wor=
d"><code><span style=3D"color:#000">&nbsp; </span><span style=3D"color:#008=
">virtual</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">static</span><span style=3D"color:#000"> freeShared</span><span style=3D=
"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span =
style=3D"color:#008">delete</span><span style=3D"color:#000"> shared_</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; <=
/span><span style=3D"color:#660">}</span></code></div></blockquote><div><br=
></div><div>I'm only proposing virtual static data members here, not virtua=
l static<i> functions</i>. Unless this was just a mistake, I'm not sure wha=
t a virtual static function is supposed to mean here. From your code it loo=
ks like it would suffice just as a normal static function.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_276_12786899.1359090190265--

.

On Thu, Jan 24, 2013 at 9:03 PM, Brent Friedman <fourthgeek@gmail.com> wrote:
>
>>   virtual static freeShared() {
>>     delete shared_;
>>   }
>
>
> I'm only proposing virtual static data members here, not virtual static
> functions. Unless this was just a mistake, I'm not sure what a virtual
> static function is supposed to mean here. From your code it looks like it
> would suffice just as a normal static function.

virtual static functions seem like a natural extension of this
proposal. Presumably they would act exactly like normal virtual
functions, except that 'this' is not implicitly passed to them.
However, as with any feature, we would need more rationale for adding
them than just that they're implementable, and that they're the
logical result of combining two existing features.

--

---
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/?hl=en.



.

------=_Part_106_5649432.1359100307012
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 25, 2013 at 1:02 AM, Richard Smith  wrote:
 Presumably they would act exactly like normal virtual
> functions, except that 'this' is not implicitly passed to them.

I see. So a virtual static function could today be best implemented as

static TY staticfunc(...){ <body> }
virtual TY func(...){ staticfunc(...); }

I see the value in virtual static functions since it allows you to call the
function statically using scope-resolution or dynamically using dynamic
type. I also see a direct similarity in these two meanings of virtual
static. I'm not sure what the convention is but this does seem like a
separate proposal though.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_106_5649432.1359100307012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Fri, Jan 25, 2013 at 1:02 AM, Richard Smith &nbsp;wrote:</div><div>=
&nbsp;Presumably they would act exactly like normal virtual</div><div>&gt; =
functions, except that 'this' is not implicitly passed to them.</div><div><=
br></div><div>I see. So a virtual static function could today be best imple=
mented as</div><div><br></div><div>static TY staticfunc(...){ &lt;body&gt; =
}</div><div>virtual TY func(...){ staticfunc(...); }</div><div><br></div><d=
iv>I see the value in virtual static functions since it allows you to call =
the function statically using scope-resolution or dynamically using dynamic=
 type. I also see a direct similarity in these two meanings of virtual stat=
ic. I'm not sure what the convention is but this does seem like a separate =
proposal though.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_106_5649432.1359100307012--

.

------=_Part_341_4819490.1359100625705
Content-Type: text/plain; charset=ISO-8859-1

*Here are some syntactic examples I cooked up assuming that we can drop the
const restriction.


class Base
{
 public:
  virtual static const bool IsSerializable=true; //each subclass advertises
serializability
  virtual static size_t CreationCount=0; //each subclass can count the
number of instances created

  Base()  {  ++CreationCount;}//Increments Base::CreationCount

 void DynamicIncrement()
 {  ++CreationCount; } // Increments ThisClass::CreationCount as chosen by
the dynamic type of this
};

class Special : public Base
{
public:
  virtual static const bool IsSerializable=false; //this class cannot be
serialized.
  Special() {  ++CreationCount; } //Increments Special::CreationCount

};

int main()
{
Base::CreationCount; // =0

Base* b = new Base;
Base::CreationCount; //=1
b->CreationCount; // = 1, accesses static Base::CreationCount
b->IsSerializable; // =true, accesses static const Base::IsSerializable

Base* s = new Special;
Base::CreationCount; //=2. Was incremented in Base::Base
s->CreationCount; // =1, accesses static Special::CreationCount
s->IsSerializable; //=false, accesses static const Special::IsSerializable
}


*

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_341_4819490.1359100625705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b id=3D"internal-source-marker_0.1670496470760554" style=3D"color: rgb(0, =
0, 0); font-family: 'Times New Roman'; font-size: medium; font-weight: norm=
al;">Here are some syntactic examples I cooked up assuming that we can drop=
 the const restriction.<br><br><div style=3D"background-color: rgb(250, 250=
, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Base</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">static<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">IsSerializable</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">true</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: #800;" class=3D"styled-by-prettify">=
//each subclass advertises serializability</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" 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">static</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> size_t </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">CreationCount</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</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: #800;" class=3D"styled-by-prettify">//each subclass =
can count the number of instances created</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br>&nbsp; </span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">Base</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> &nbsp;</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">++</span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>CreationCount</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;}</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//In=
crements Base::CreationCount</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br>&nbsp;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">DynamicIncrement</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>&nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">CreationCount=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan 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: #800;" =
class=3D"styled-by-prettify">// Increments ThisClass::CreationCount as chos=
en by the dynamic type of this</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Special</s=
pan><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: #=
008;" class=3D"styled-by-prettify">public</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Base</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">pub=
lic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">static</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">IsSerializable</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">false</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//this class cannot =
be serialized.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Special</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">CreationCount</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//Increments Special::CreationCount </span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Base</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">CreationCount</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: #800;" =
class=3D"styled-by-prettify">// =3D0</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Base</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">CreationCount</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
=3D1</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>b<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">CreationCount</s=
pan><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: #800;" class=3D"styled-by-prettify">// =3D 1, accesses static Base:=
:CreationCount</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-=
&gt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">IsSeri=
alizable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// =3Dtrue, accesses=
 static const Base::IsSerializable</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> s </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Special</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">CreationCount</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//=3D2. Was incremented in Base::Base</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">CreationCount</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: #800;" class=3D"styled-by-pret=
tify">// =3D1, accesses static Special::CreationCount</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>s</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">IsSerializable</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//=3Dfalse, accesses static const Special::IsSerializabl=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></c=
ode></div><span style=3D"font-size: 15px; font-family: Arial; background-co=
lor: transparent; white-space: pre-wrap;"><br></span></b><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_341_4819490.1359100625705--

.

Given:

struct A {
  virtual static const int x = 0;
};
struct B : A {
};

Do we need a definition, "const int A::x;", if we odr-use A::x?
Do we need a definition if we don't odr-use A::x? (Are all virtual
static data members odr-used in the same way that all virtual
functions are?)
Do we have &A::x == &B::x?

(I think the answers should be: yes, yes, and yes.)

On Thu, Jan 24, 2013 at 11:57 PM, Brent Friedman <fourthgeek@gmail.com> wrote:
> Here are some syntactic examples I cooked up assuming that we can drop the
> const restriction.
>
>
> class Base
> {
>  public:
>   virtual static const bool IsSerializable=true; //each subclass advertises
> serializability
>   virtual static size_t CreationCount=0; //each subclass can count the
> number of instances created
>
>   Base()  {  ++CreationCount;}//Increments Base::CreationCount
>
>  void DynamicIncrement()
>  {  ++CreationCount; } // Increments ThisClass::CreationCount as chosen by
> the dynamic type of this
> };
>
> class Special : public Base
> {
> public:
>   virtual static const bool IsSerializable=false; //this class cannot be
> serialized.
>   Special() {  ++CreationCount; } //Increments Special::CreationCount
>
> };
>
> int main()
> {
> Base::CreationCount; // =0
>
> Base* b = new Base;
> Base::CreationCount; //=1
> b->CreationCount; // = 1, accesses static Base::CreationCount
> b->IsSerializable; // =true, accesses static const Base::IsSerializable
>
> Base* s = new Special;
> Base::CreationCount; //=2. Was incremented in Base::Base
> s->CreationCount; // =1, accesses static Special::CreationCount
> s->IsSerializable; //=false, accesses static const Special::IsSerializable
> }
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to
> std-proposals+unsubscribe@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

2013/1/25 Richard Smith <richard@metafoo.co.uk>:
> Given:
>
> struct A {
>   virtual static const int x = 0;
> };
> struct B : A {
> };
>
> Do we need a definition, "const int A::x;", if we odr-use A::x?
> Do we need a definition if we don't odr-use A::x? (Are all virtual
> static data members odr-used in the same way that all virtual
> functions are?)
> Do we have &A::x == &B::x?
>
> (I think the answers should be: yes, yes, and yes.)

I agree with the first and second, but given that we have

"Otherwise if either is a pointer to a virtual member function, the
result is unspecified."

I would expect "unspecified" for the last (I don't know, why we have
this special unspecified rule here).

- Daniel

--

---
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/?hl=en.



.

On Fri, Jan 25, 2013 at 12:22 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> 2013/1/25 Richard Smith <richard@metafoo.co.uk>:
>> Given:
>>
>> struct A {
>>   virtual static const int x =3D 0;
>> };
>> struct B : A {
>> };
>>
>> Do we need a definition, "const int A::x;", if we odr-use A::x?
>> Do we need a definition if we don't odr-use A::x? (Are all virtual
>> static data members odr-used in the same way that all virtual
>> functions are?)
>> Do we have &A::x =3D=3D &B::x?
>>
>> (I think the answers should be: yes, yes, and yes.)
>
> I agree with the first and second, but given that we have
>
> "Otherwise if either is a pointer to a virtual member function, the
> result is unspecified."
>
> I would expect "unspecified" for the last (I don't know, why we have
> this special unspecified rule here).

I think we would need to specify this for virtual static data members,
if they are allowed to be non-const.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_124_23269130.1359127253841
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 25, 2013 at 12:22 AM, Daniel Kr=FCgler  wrote:=20
>
> > 2013/1/25 Richard Smith=20
> >> Given:=20
> >>=20
> >> struct A {=20
> >>   virtual static const int x =3D 0;=20
> >> };=20
> >> struct B : A {=20
> >> };=20
> >>=20
> >> Do we need a definition, "const int A::x;", if we odr-use A::x?=20
> >> Do we need a definition if we don't odr-use A::x? (Are all virtual=20
> >> static data members odr-used in the same way that all virtual=20
> >> functions are?)=20
> >> Do we have &A::x =3D=3D &B::x?=20
> >>=20
> >> (I think the answers should be: yes, yes, and yes.)=20
>
> The answer to (3) depends on the exact semantics of virtual static. Here=
=20
I've assumed it means 'Each subclass automatically receives an instance of=
=20
this type', but it could mean 'Any subclass may receive an instance of this=
=20
type, if requested'. The vision here was accessing arbitrary data at=20
vtable+offset and for the compiler to support that every subclass would be=
=20
required to receive a copy of the data to keep everything aligned properly.=
=20
In that case we should work with the natural implementation and say all=20
subtypes receive this data. It would mean &A::x !=3D &B::x.

I don't think that a separate A::x or B::x definition should be required.=
=20
The storage-class specifier of virtual static is sufficient to give the=20
compiler all the necessary information it needs. Static data must be stored=
=20
in exactly one translation unit so creating a definition makes sense. With=
=20
virtual static it is the compiler's duty to decide where the data is=20
placed. Creating a definition for virtual static data in an arbitrary=20
translation unit would seem to conflict with that. If the virtual static=20
data is only declared but not defined then it should be valid to define the=
=20
value separately but that would have no effect on where the compiler places=
=20
the data. Additionally, given my above answer, it would seem quite unusual=
=20
if you created struct B above and received a compilation error because B::x=
=20
was not defined.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_124_23269130.1359127253841
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 25, 2013 at 12:22 AM, Daniel Kr=FCgler &nbsp;wrote:&nbsp;<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">&gt; 2013/1/25 Richard Smith&nbsp;<b=
r>&gt;&gt; Given:
<br>&gt;&gt;
<br>&gt;&gt; struct A {
<br>&gt;&gt; &nbsp; virtual static const int x =3D 0;
<br>&gt;&gt; };
<br>&gt;&gt; struct B : A {
<br>&gt;&gt; };
<br>&gt;&gt;
<br>&gt;&gt; Do we need a definition, "const int A::x;", if we odr-use A::x=
?
<br>&gt;&gt; Do we need a definition if we don't odr-use A::x? (Are all vir=
tual
<br>&gt;&gt; static data members odr-used in the same way that all virtual
<br>&gt;&gt; functions are?)
<br>&gt;&gt; Do we have &amp;A::x =3D=3D &amp;B::x?
<br>&gt;&gt;
<br>&gt;&gt; (I think the answers should be: yes, yes, and yes.)
<br><br></blockquote><div>The answer to (3) depends on the exact semantics =
of virtual static. Here I've assumed it means 'Each subclass automatically =
receives an instance of this type', but it could mean 'Any subclass may rec=
eive an instance of this type, if requested'. The vision here was accessing=
 arbitrary data at vtable+offset and for the compiler to support that every=
 subclass would be required to receive a copy of the data to keep everythin=
g aligned properly. In that case we should work with the natural implementa=
tion and say all subtypes receive this data. It would mean &amp;A::x !=3D &=
amp;B::x.<br></div><div><br></div><div>I don't think that a separate A::x o=
r B::x definition should be required. The storage-class specifier of virtua=
l static is sufficient to give the compiler all the necessary information i=
t needs. Static data must be stored in exactly one translation unit so crea=
ting a definition makes sense. With virtual static it is the compiler's dut=
y to decide where the data is placed. Creating a definition for virtual sta=
tic data in an arbitrary translation unit would seem to conflict with that.=
 If the virtual static data is only declared but not defined then it should=
 be valid to define the value separately but that would have no effect on w=
here the compiler places the data. Additionally, given my above answer, it =
would seem quite unusual if you created struct B above and received a compi=
lation error because B::x was not defined.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_124_23269130.1359127253841--

.

Virtual functions provide great flexibility in that their operation can
be modified by both the class they are defined in (determining which
override is called) and the instance they are called on (by examining
*this).  But the second part of this flexibility is sometimes not
needed; but we still pay for it with an indirect function call:


   struct base {

     const char* class_name() const = 0;

     size_t size() const = 0;

   };


   struct derived : base {

     const char* class_name() const { return "derived"; } // *this not
examined

     size_t size() const { return sizeof(*this); } // *this not examined

     // more stuff

   };


We could provide a way to express behavior that depends on the class but
not on the instance:


   struct base {

     static virtual const char* const class_name;  // can't use = 0,
unfortunately

     static virtual const size_t size;

   };


   struct derived : base {

     static virtual const char* const class_name = "derived";

     static virtual const size_t size = sizeof(derived);

     // more stuff

   };


Implementations could simply virtual data members in vtables, or
pointers to them if they are non-const (so a derived class that doesn't
override shares the variable with its parent).  In effect, virtual data
members are static, but each derived type has its own version of these
variables.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6894cd0-35fe-ad2e-d510-bfdfab30605f%40scylladb.com.

.

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

Here's an old thread on that topic for a discussion of some of the problems
to overcome.

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/virtual$20static$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ


On Sun, Feb 12, 2017 at 4:50 AM, Avi Kivity <avi@scylladb.com> wrote:

> Virtual functions provide great flexibility in that their operation can be
> modified by both the class they are defined in (determining which override
> is called) and the instance they are called on (by examining *this).  But
> the second part of this flexibility is sometimes not needed; but we still
> pay for it with an indirect function call:
>
>
>   struct base {
>
>     const char* class_name() const = 0;
>
>     size_t size() const = 0;
>
>   };
>
>
>   struct derived : base {
>
>     const char* class_name() const { return "derived"; } // *this not
> examined
>
>     size_t size() const { return sizeof(*this); } // *this not examined
>
>     // more stuff
>
>   };
>
>
> We could provide a way to express behavior that depends on the class but
> not on the instance:
>
>
>   struct base {
>
>     static virtual const char* const class_name;  // can't use = 0,
> unfortunately
>
>     static virtual const size_t size;
>
>   };
>
>
>   struct derived : base {
>
>     static virtual const char* const class_name = "derived";
>
>     static virtual const size_t size = sizeof(derived);
>
>     // more stuff
>
>   };
>
>
> Implementations could simply virtual data members in vtables, or pointers
> to them if they are non-const (so a derived class that doesn't override
> shares the variable with its parent).  In effect, virtual data members are
> static, but each derived type has its own version of these variables.
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/f6894cd0-35fe-ad2e-d510-
> bfdfab30605f%40scylladb.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%40mail.gmail.com.

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

<div dir=3D"ltr">Here&#39;s an old thread on that topic for a discussion of=
 some of the problems to overcome.<div><br></div><div><a href=3D"https://gr=
oups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/virtual$20stati=
c$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ">https://groups.g=
oogle.com/a/isocpp.org/forum/#!searchin/std-proposals/virtual$20static$20da=
ta$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ</a><br></div><div><br><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun=
, Feb 12, 2017 at 4:50 AM, Avi Kivity <span dir=3D"ltr">&lt;<a href=3D"mail=
to:avi@scylladb.com" target=3D"_blank">avi@scylladb.com</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">Virtual functions provide great flexib=
ility in that their operation can be modified by both the class they are de=
fined in (determining which override is called) and the instance they are c=
alled on (by examining *this).=C2=A0 But the second part of this flexibilit=
y is sometimes not needed; but we still pay for it with an indirect functio=
n call:<br>
<br>
<br>
=C2=A0 struct base {<br>
<br>
=C2=A0 =C2=A0 const char* class_name() const =3D 0;<br>
<br>
=C2=A0 =C2=A0 size_t size() const =3D 0;<br>
<br>
=C2=A0 };<br>
<br>
<br>
=C2=A0 struct derived : base {<br>
<br>
=C2=A0 =C2=A0 const char* class_name() const { return &quot;derived&quot;; =
} // *this not examined<br>
<br>
=C2=A0 =C2=A0 size_t size() const { return sizeof(*this); } // *this not ex=
amined<br>
<br>
=C2=A0 =C2=A0 // more stuff<br>
<br>
=C2=A0 };<br>
<br>
<br>
We could provide a way to express behavior that depends on the class but no=
t on the instance:<br>
<br>
<br>
=C2=A0 struct base {<br>
<br>
=C2=A0 =C2=A0 static virtual const char* const class_name;=C2=A0 // can&#39=
;t use =3D 0, unfortunately<br>
<br>
=C2=A0 =C2=A0 static virtual const size_t size;<br>
<br>
=C2=A0 };<br>
<br>
<br>
=C2=A0 struct derived : base {<br>
<br>
=C2=A0 =C2=A0 static virtual const char* const class_name =3D &quot;derived=
&quot;;<br>
<br>
=C2=A0 =C2=A0 static virtual const size_t size =3D sizeof(derived);<br>
<br>
=C2=A0 =C2=A0 // more stuff<br>
<br>
=C2=A0 };<br>
<br>
<br>
Implementations could simply virtual data members in vtables, or pointers t=
o them if they are non-const (so a derived class that doesn&#39;t override =
shares the variable with its parent).=C2=A0 In effect, virtual data members=
 are static, but each derived type has its own version of these variables.<=
span class=3D"HOEnZb"><font color=3D"#888888"><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" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6894cd0-35fe-ad2e-d510-bfdfab30605f%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f6894cd0-35fe-ad2e-d510-<w=
br>bfdfab30605f%40scylladb.com</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-=
h6qj4WA7skfaG1ZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRprTyJ=
d8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%40mail.gmail.com</a>.<br />

--001a11c18268afe377054857b79a--

.

This is a multi-part message in MIME format.
--------------223CE6F80FFB98FA035F465A
Content-Type: text/plain; charset=UTF-8; format=flowed

Thanks for that.  It looks like the major obstacle is the natural
resistance to change (not that it's bad, a feature has to be worthwhile
to be added to the language).  I don't think this one is compelling, but
on the other hand, it seems a generalization of virtual functions (which
are more or less virtual static data members of type pointer to member
function).


On 02/12/2017 06:21 PM, Brittany Friedman wrote:
> Here's an old thread on that topic for a discussion of some of the
> problems to overcome.
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/virtual$20static$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ
> <https://groups.google.com/a/isocpp.org/forum/#%21searchin/std-proposals/virtual$20static$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ>
>
>
> On Sun, Feb 12, 2017 at 4:50 AM, Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>> wrote:
>
>     Virtual functions provide great flexibility in that their
>     operation can be modified by both the class they are defined in
>     (determining which override is called) and the instance they are
>     called on (by examining *this).  But the second part of this
>     flexibility is sometimes not needed; but we still pay for it with
>     an indirect function call:
>
>
>       struct base {
>
>         const char* class_name() const = 0;
>
>         size_t size() const = 0;
>
>       };
>
>
>       struct derived : base {
>
>         const char* class_name() const { return "derived"; } // *this
>     not examined
>
>         size_t size() const { return sizeof(*this); } // *this not
>     examined
>
>         // more stuff
>
>       };
>
>
>     We could provide a way to express behavior that depends on the
>     class but not on the instance:
>
>
>       struct base {
>
>         static virtual const char* const class_name;  // can't use =
>     0, unfortunately
>
>         static virtual const size_t size;
>
>       };
>
>
>       struct derived : base {
>
>         static virtual const char* const class_name = "derived";
>
>         static virtual const size_t size = sizeof(derived);
>
>         // more stuff
>
>       };
>
>
>     Implementations could simply virtual data members in vtables, or
>     pointers to them if they are non-const (so a derived class that
>     doesn't override shares the variable with its parent).  In effect,
>     virtual data members are static, but each derived type has its own
>     version of these variables.
>
>
>     --
>     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%2Bunsubscribe@isocpp.org>.
>     To post to this group, send email to std-proposals@isocpp.org
>     <mailto:std-proposals@isocpp.org>.
>     To view this discussion on the web visit
>     https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6894cd0-35fe-ad2e-d510-bfdfab30605f%40scylladb.com
>     <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6894cd0-35fe-ad2e-d510-bfdfab30605f%40scylladb.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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a909d79-a125-2a4e-ed42-107bc4d497aa%40scylladb.com.

--------------223CE6F80FFB98FA035F465A
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">
    <p>Thanks for that.=C2=A0 It looks like the major obstacle is the natur=
al
      resistance to change (not that it's bad, a feature has to be
      worthwhile to be added to the language).=C2=A0 I don't think this one
      is compelling, but on the other hand, it seems a generalization of
      virtual functions (which are more or less virtual static data
      members of type pointer to member function).<br>
    </p>
    <br>
    <div class=3D"moz-cite-prefix">On 02/12/2017 06:21 PM, Brittany
      Friedman wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CADbh+eRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">Here's an old thread on that topic for a discussion
        of some of the problems to overcome.
        <div><br>
        </div>
        <div><a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/forum/#%21searchin/std-propo=
sals/virtual$20static$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKU=
QJ">https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/v=
irtual$20static$20data$20members/std-proposals/Z1QG_3Mrn0Y/lzrwNxDeKUQJ</a>=
<br>
        </div>
        <div><br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">On Sun, Feb 12, 2017 at 4:50 AM, Avi
          Kivity <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylla=
db.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">Virtual
            functions provide great flexibility in that their operation
            can be modified by both the class they are defined in
            (determining which override is called) and the instance they
            are called on (by examining *this).=C2=A0 But the second part o=
f
            this flexibility is sometimes not needed; but we still pay
            for it with an indirect function call:<br>
            <br>
            <br>
            =C2=A0 struct base {<br>
            <br>
            =C2=A0 =C2=A0 const char* class_name() const =3D 0;<br>
            <br>
            =C2=A0 =C2=A0 size_t size() const =3D 0;<br>
            <br>
            =C2=A0 };<br>
            <br>
            <br>
            =C2=A0 struct derived : base {<br>
            <br>
            =C2=A0 =C2=A0 const char* class_name() const { return "derived"=
; } //
            *this not examined<br>
            <br>
            =C2=A0 =C2=A0 size_t size() const { return sizeof(*this); } // =
*this
            not examined<br>
            <br>
            =C2=A0 =C2=A0 // more stuff<br>
            <br>
            =C2=A0 };<br>
            <br>
            <br>
            We could provide a way to express behavior that depends on
            the class but not on the instance:<br>
            <br>
            <br>
            =C2=A0 struct base {<br>
            <br>
            =C2=A0 =C2=A0 static virtual const char* const class_name;=C2=
=A0 // can't
            use =3D 0, unfortunately<br>
            <br>
            =C2=A0 =C2=A0 static virtual const size_t size;<br>
            <br>
            =C2=A0 };<br>
            <br>
            <br>
            =C2=A0 struct derived : base {<br>
            <br>
            =C2=A0 =C2=A0 static virtual const char* const class_name =3D "=
derived";<br>
            <br>
            =C2=A0 =C2=A0 static virtual const size_t size =3D sizeof(deriv=
ed);<br>
            <br>
            =C2=A0 =C2=A0 // more stuff<br>
            <br>
            =C2=A0 };<br>
            <br>
            <br>
            Implementations could simply virtual data members in
            vtables, or pointers to them if they are non-const (so a
            derived class that doesn't override shares the variable with
            its parent).=C2=A0 In effect, virtual data members are static,
            but each derived type has its own version of these
            variables.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
                <br>
                <br>
                -- <br>
                You received this message because you are subscribed to
                the Google Groups "ISO C++ Standard - Future Proposals"
                group.<br>
                To unsubscribe from this group and stop receiving emails
                from it, send an email to <a moz-do-not-send=3D"true"
                  href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
                  target=3D"_blank">std-proposals+unsubscribe@isoc<wbr>pp.o=
rg</a>.<br>
                To post to this group, send email to <a
                  moz-do-not-send=3D"true"
                  href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
                To view this discussion on the web visit <a
                  moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6894c=
d0-35fe-ad2e-d510-bfdfab30605f%40scylladb.com"
                  rel=3D"noreferrer" target=3D"_blank">https://groups.googl=
e.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f6894cd0-35fe-ad2e-d510-=
<wbr>bfdfab30605f%40scylladb.com</a>.<br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
      -- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      To view this discussion on the web visit <a
        moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%=
2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%40mail.gmail.com?utm_medium=
=3Demail&amp;utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/CADbh%2BeRprTyJd8XpRxUrTj6-oFUpeGiQk-h6qj4WA7skfaG1ZA%4=
0mail.gmail.com</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a909d79-a125-2a4e-ed42-107bc4d497aa%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/9a909d79-a125-2a4e-ed42-107bc4d497=
aa%40scylladb.com</a>.<br />

--------------223CE6F80FFB98FA035F465A--

.