Class ClassA
{
    virtual static int Var;

    virtual static void Something();
}

Class ClassB : ClassA
{
    virtual static void Something();
}

And you wouldn't use a just an object reference, you'd use the class name.

ClassA.Something();
ClassB.Something();

ClassA.Var = 11; //Class a's Var has 11
ClassB.Var = 10; //Class b's Var has 10 and class A's var still has 11

Although using a object reference may make sense sometimes.

Basicly to deal with properties and methods that are one per class not per class and all child classes as well.  It treats a class as the group of objects on one level.

There are work-arounds, but why use them when you could use the proper thing.

I'm sure there's gota be a better reason then that. Parhaps it's to hard to implement in the complier, parhaps it's ineffecient, parhaps it should be defined using a parallel object sturcture.

Here's a few other newsgroup links that portray the same opinion (I couldn't find any good reasons against so that's why I'm asking).

http://dbforums.com/archive/89/2001/06/1/65121 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&th=ca8b a27e7944e9ab&rnum=1 http://groups.google.com/groups?q=%22static+virtual+methods%22+%22C%2B%2B%22 &hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3904%40lulea.trab.se&rnum=5


"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ailbl9$18sd$1@digitaldaemon.com...
> Because it doesn't make sense to call a static method through an object reference?  But how else do you get the compiler to "figure out" which version of the function to call?  Seems you either want a static function (non-virtual) or a virtual member function.
>
> How would you use one if you had the capability?
>
> Sean
>
> "anderson" <anderson@firestar.com.au> wrote in message news:aikj9d$2bh1$1@digitaldaemon.com...
> > Just wondering what the argument against virtual static members is? I've never read anything against them in books. I'm sure there's a good
reason
> > they weren't implemented in C++. So what it the reasoning against
virtual
> > static members?
> >
> > Thanks
>
>
>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374717849229282@news.digitalmars.com...
> I think that user-defined operator precedence is just too complex, and mostly unused feature. Does it really worth Walter's time to spend to implement it?

I think it's not a good idea to implement. For one thing, it breaks the idea of separating the syntactical from the semantic analysis.

"anderson" <anderson@firestar.com.au> wrote in message news:aikj9d$2bh1$1@digitaldaemon.com...

> Just wondering what the argument against virtual static members is? I've never read anything against them in books. I'm sure there's a good reason they weren't implemented in C++. So what it the reasoning against virtual static members?

   What you mean is having a global function that can dynamically dispatch
according to an object's real type. That can definitely be done (see Mozart
in SourceForge), but it is a bit complicated. In C++ and D, dynamic dispatch
is designed for virtual function tables, although that particular
implementation is not necessarily used. This was done by requiring every
class to know, beforehand, all the functions it'll dynamically dispatch to.
The "object.function()" syntax can be seen as just syntactic sugar, really.
Allowing arbitrary virtual functions to be added outside of the class would
require a different method. The upside of this is that, if such a method is
implemented, multiple dynamic dispatch comes naturally (that's why Mozart
supports it).

   It would be a worthwhile addition to the language, except for all the
complication (which is quite a bit).

Salutaciones,
                         JCAB

Thanks.

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ajcd0u$2g3a$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:aikj9d$2bh1$1@digitaldaemon.com...
>
> > Just wondering what the argument against virtual static members is? I've never read anything against them in books. I'm sure there's a good
reason
> > they weren't implemented in C++. So what it the reasoning against
virtual
> > static members?
>
>    What you mean is having a global function that can dynamically dispatch
> according to an object's real type. That can definitely be done (see
Mozart
> in SourceForge), but it is a bit complicated. In C++ and D, dynamic
dispatch
> is designed for virtual function tables, although that particular implementation is not necessarily used. This was done by requiring every class to know, beforehand, all the functions it'll dynamically dispatch
to.
> The "object.function()" syntax can be seen as just syntactic sugar,
really.
> Allowing arbitrary virtual functions to be added outside of the class
would
> require a different method. The upside of this is that, if such a method
is
> implemented, multiple dynamic dispatch comes naturally (that's why Mozart
> supports it).
>
>    It would be a worthwhile addition to the language, except for all the
> complication (which is quite a bit).
>
> Salutaciones,
>                          JCAB
>
>
>

I think the precedence for the operator, which way it runs (left to right, or vice versa), and whether it is a postfix, prefix, or not should be left to the default settings. If it's a left -> right operator, the operator function for the object on the left is called. It could be defined like this:

class myClass {
	int w = 0, x = 5;
	operator(+, int i) {return w + x + i;} // the operator is passed as the first argument to operator function
	operator(+, myClass i) {return w + x + i.w + i.x } // the call to operator function is chosen by which operator is used and w/ which data type
}