🚀 go-pugleaf

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