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

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

In article <487q1e$peq@aztec.co.za>, dharley@aztec.co.za (David Harley) wrote:

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

try :

class Base {
    virtual data_type& data() { static data_type BaseData; return BaseData; }
    };

class Derived : Base {
    virtual data_type& data() { static data_type DerivedData; return
DerivedData; }
    };

I agree that virtual-static-data and virtual-static-member-functions are
something that is missing in the language, can be easily added and will be
useful.

-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

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

I'm not sure what you are trying to accomplish but it seems that
implementing a virtual function that returns a pointer to a static
member is what you want.

dharley@aztec.co.za (David Harley) wrote:

>
>Is there any good reason why the following is disallowed?
>
>class A
>{
>  virtual static s;
>  f() { do something with s }
>}
>
[SNIP]



[ 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 <488hg6$prm@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>Virtual things are associated with an object; static things are not
>associated with any object.

I think maybe you need to "think outside the box" a bit more :-).  The whole 
issue is whether such a restrictive viewpoint is appropriate.  A reasonable 
point of view is that virtual and static are completely orthogonal and
intersect quite nicely.  Virtual things depend on the actual type of the 
referenced object.  Static things are associated with the class of an object 
rather than with a specific instance.  Ergo, static virtual things depend on the
actual class of the referenced object, rather than the static type of the
expression by which you reference it.

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

I won't try to defend virtual data members, but static virtual functions solve 
the problem of safely invoking derived class code from within base class 
constructors and destructors (a programming problem which 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?"

No.  I say that because one of those "other places" is here and clearly the 
criteria expressed implicitly during discussion of this issue indicates that 
the value of static virtual functions is too subtle to be appreciated, I guess.
That's cool.  I can't appreciate the subtle value in having all my for loops
being broken.  I do, however, acknowledge the arguments in favor of doing that.

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

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