In <MATT.95Nov13154705@cyclops5.berkeley.edu>, matt@cyclops5.berkeley.edu (Matt Austern) writes:
>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."
>---

But they also solve other real problems that your solutions cannot.

Calls to static virtual functions could be dispatched to the most-derived
class's implementation when invoked from within base class constructors and
destructors.

Bill Law


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

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

Is there any good reason why the following is disallowed?

class A
{
  virtual static s;
  f() { do something with s }
}

class B : A
{
  virtual static s;
...
}

 - the idea being, that each subclass of A can posess its own static member
that doesn't interfere with other subclasses, but which can be accessed
by methods of A.

The only work-around seems to be to declare s as non-static in A, and then
assign the static variable in the B's to A's s in B's constructor's (maybe
I should have used x instead of s!)

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

In article peq@aztec.co.za, dharley@aztec.co.za (David Harley) writes:
>
>Is there any good reason why the following is disallowed?
>
>class A
>{
>  virtual static s;
>  f() { do something with s }
>}
>
>class B : A
>{
>  virtual static s;
>....
>}
>
> - the idea being, that each subclass of A can posess its own static member
>that doesn't interfere with other subclasses, but which can be accessed
>by methods of A.

There is no technical reason why we couldn't have virtual data,
virtual static data, and virtual static functions. The problem with
virtual static [ functions | data ] is a collision of semantics:
Virtual things are associated with an object; static things are not
associated with any object.

People sometimes propose a rule like "If you access the item via an
object pointer or reference, the actual object type determines which
static thing you get; otherwise you get the thing associated with the
static type of the access."

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?"

---
Steve Clamage, stephen.clamage@eng.sun.com



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