🚀 go-pugleaf

In article <488hg6$prm@engnews1.eng.sun.com>
clamage@Eng.Sun.COM (Steve Clamage) writes:

> In your example, we might have
> 	A a;
> 	A* ap = new B;
> 	a.s   // gets A::s
> 	ap->s // gets B::s
> 
> That's workable, if a bit kludgy, but it isn't obvious to me (among others)
> what programming problem is solved by this extra complication that can't be
> solved adequately already. By that, I don't mean "Can you think of a problem
> that this extension solves?" I do mean "Considering the criteria expressed
> in D&E and other places for extensions to C++, is this a good candidate?"

My own opinion is that virtual static members would occasionally be
useful, and I do occasionally miss them, but that it is already
possible to do pretty much everything that you'd want to use virtual
static members for.  

The case when they would be nice is if you have some piece of
information that is shared between all objects of a class, but that is
different for each class in a hierarchy.  Some sort of type code, for
example, that you use when you're saving object to and restoring them
from permanent storage.  It's useful, in cases like that, to be able
to refer to something like that both as B::code() and as A->code().

There are other ways you can achieve the same effect, though.  The
most obvious one is just to have two functions for each class in your
hierarchy, one static and one virtual, where the virtual function
simply calls the static function.  Another solution is to define only
the virtual function, and then provide an exemplar for each class in
your hierarchy; instead of B::code(), you'd write something like
B_exemplar.code().

To answer Steve's question, then, I don't think that virtual static
functions are a good candidate for a C++ extension.  They solve a real
problem, but it's a problem that can be solved already.

-- 
  Matt Austern                             He showed his lower teeth.  "We
  matt@physics.berkeley.edu                all have flaws," he said, "and
  http://dogbert.lbl.gov/~matt             mine is being wicked."
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]