Thanks Hyman, that example really clears up the issue for me. Thanks

Samee

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
> Samee Zahur wrote:
>
>> static member functions can never be virtual. Why isn't anything like
>> this allowed?
>
> We've had this discussion a million times. The killer counterexample is
>
>     struct x {
>         static virtual void f() { cout << "x::f\n"; }
>         static virtual void g() { f(); }
>     };
>     struct y : x {
>         static virtual void f() { cout << "y::f\n"; }
>     }
>     int main() { y a; a.g(); }

Compilation error on the line with function g() calling f().
It's not possible, and never has been, to call a virtual function
from within a static function.

Change that line to:
   static virtual void g() { x::f(); }
and the result of the program will not be more unexpected than
a non-static version.

So what's so killing about this counterexample? The fact that people
might expect it to compile?

Sjoerd

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Whipp wrote:
> I know I've seen this counter-example before, but I've never
understood
> why people believe it to be a "killer". The reasoning seems to be
that
> a static function is required to be assignable to a function pointer
--
> and so cannot have an implementation that carries additional context.
> But that objection is easily solved by saying that a "virtual" static
> does not need to be assignable to a simple function pointer.

How about the following counterexample.

struct A
{
  virtual void foo() { }
  void bar() { foo(); }
  virtual void baz() { bar(); }

  virtual static void sfoo() { }
  static void sbar() { sfoo(); }
  virtual static void sbaz() { sbar(); }
};

struct B : A
{
  virtual void foo() { }
  virtual void baz() { bar(); }

  virtual static void sfoo() { }
  virtual static void sbaz() { sbar(); }
};

int main()
{
  B b;  A& a = b;
  a.baz();     // B::baz() calls A::bar() calls B::foo()
  a.sbaz();   // B::sbaz() calls A::sbar() calls A::sfoo!
  B::sbaz();  // Equivalent: B::sbaz() calls A::sbar() calls A::sfoo.
}

So, the problem is as follows: in nonvirtual nonstatic member
functions, the underlying type information is still present in the
context in the form of the this pointer, and it can be used in
subsequent virtual dispatches. But if static nonvirtual member
functions are supposed to be "additional-contextless", as you say, then
they cannot preserve this information to perform later method calls.
And if calling a nonvirtual static member function means losing all
type context, all nested calls from such a function to *virtual* static
member functions can only be dispatched using the type information
available -- which is static type information.

Another big difference is that virtual static functions would not
possibly be able to preserve the type binding through external
functions like virtual nonstatic functions can:

void foo(A& a);

struct A
{
  virtual void callback(){}
};

struct B
{
  virtual void callback(){}
  void bar() {
    foo(this); // calls B::callback() on this
  }
};

void foo(A& a)
{
  a.callback();
}

This kind of construct simply won't work when the binding isn't
represented by an object entity such as the "this" pointer, something
that you can pass around.

--Bart

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In a recent post in comp.lang.c++ I came to know that static member
functions can never be virtual. So I am wondering why this restriction
is in place ... although it usually makes more sense to call static
functions like this : cls::fun() : it *can* also be called like this
:obj.fun(): - with the same effect. So, couldn't the compiler use
runtime resolution of the version function of the function to call when
the second form is used with obj of type cls&  ?? That is, if fun was
declared as virtual static fun(...) in cls. Why isn't anything like
this allowed? The run-time type would then determine the set of static
variables the function is allowed to use.

Samee

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Samee Zahur wrote:
> In a recent post in comp.lang.c++ I came to know that static member
> functions can never be virtual. So I am wondering why this restriction
> is in place ... although it usually makes more sense to call static
> functions like this : cls::fun() : it *can* also be called like this
> :obj.fun(): - with the same effect. So, couldn't the compiler use
> runtime resolution of the version function of the function to call when
> the second form is used with obj of type cls&  ?? That is, if fun was
> declared as virtual static fun(...) in cls. Why isn't anything like
> this allowed? The run-time type would then determine the set of static
> variables the function is allowed to use.

If your member function should be called on some object as in obj.fun(),
why don't you just make it non-static?

Static member functions are meant not to be called on a specific object,
but to be shared among all instances of the class. (Note that if fun() is
a static member function of class cls, obj.fun() is a syntactic variation
of and exactly the same as cls::fun().) Virtuality doesn't fit here.

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Samee Zahur wrote:
> static member functions can never be virtual. Why isn't anything like
> this allowed?

We've had this discussion a million times. The killer counterexample is

     struct x {
         static virtual void f() { cout << "x::f\n"; }
         static virtual void g() { f(); }
     };
     struct y : x {
         static virtual void f() { cout << "y::f\n"; }
     }
     int main() { y a; a.g(); }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Samee Zahur" wrote:
> In a recent post in comp.lang.c++ I came to know that static member
> functions can never be virtual. So I am wondering why this restriction
> is in place ... although it usually makes more sense to call static
> functions like this : cls::fun() : it *can* also be called like this
> :obj.fun(): - with the same effect. So, couldn't the compiler use
> runtime resolution of the version function of the function to call when
> the second form is used with obj of type cls&  ?? That is, if fun was
> declared as virtual static fun(...) in cls.

That could be made to work (claims to the the contrary notwithstanding).

> Why isn't anything like this allowed?

I'll have to let the language designers answer that for you.

Mike Heard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

samee.zahur@gmail.com (Samee Zahur) wrote (abridged):
> In a recent post in comp.lang.c++ I came to know that static member
> functions can never be virtual. So I am wondering why this restriction
> is in place

To resolve the virtual functions properly would need some kind of
metaclass system - in other words, classes would need to be reified as
objects at run-time. For example, static member variables could become
ordinary members of the class object, and static member functions could
have a "this" which pointed to that (static) object.

Other languages use that approach, eg Smalltalk, and it's very useful. To
introduce it into C++ you have to overcome 3 problems:

(1) Avoiding overhead for people who don't use it.
(2) Keeping compatibility with C.
(3) Overcoming resistance of other users who don't believe it's possible
or useful.

In practice, if you need a metaclass system, it's probably easier to roll
your own in the places that you need it.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I know I've seen this counter-example before, but I've never understood
why people believe it to be a "killer". The reasoning seems to be that
a static function is required to be assignable to a function pointer --
and so cannot have an implementation that carries additional context.
But that objection is easily solved by saying that a "virtual" static
does not need to be assignable to a simple function pointer.

For whatever reason, people like the "template-method pattern"; and
many desire to apply it to a non-method. Even if this is not
particularly useful in a language like C++ (it would be much more
useful in a language like Java, IMHO, because there all functions are
static-members), I always find it very unconvincing to have an idea
dismissed by implementation-oriented objections that could easily be
overcome if the original idea had sufficient merit.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Hyman Rosen,

Hyman Rosen schrieb:

> Samee Zahur wrote:
>
>> static member functions can never be virtual. Why isn't anything like
>> this allowed?
>
>
> We've had this discussion a million times. The killer counterexample is
>
>     struct x {
>         static virtual void f() { cout << "x::f\n"; }
>         static virtual void g() { f(); }
>     };
>     struct y : x {
>         static virtual void f() { cout << "y::f\n"; }
>     }
>     int main() { y a; a.g(); }

Why should that be a killer example? Killer for what?

It is clear that virtual static's could not be simply introduced by only
allowing a
"virtual" keyword in combination with a static function member (or even
data member),
but it could be done, because its already possible to simulate it with
the current language.
But this simulation using meta classes is:

- nasty to write.
- w/o consistency support by the compiler, because some relations have to be
  enforced by consent, not by the language rules.

Greetings from Bremen,

Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:

> Samee Zahur wrote:
>
>> static member functions can never be virtual. Why isn't anything like
>> this allowed?
>
>
> We've had this discussion a million times. The killer counterexample is
>
>     struct x {
>         static virtual void f() { cout << "x::f\n"; }
>         static virtual void g() { f(); }
>     };
>     struct y : x {
>         static virtual void f() { cout << "y::f\n"; }
>     }
>     int main() { y a; a.g(); }

Not a valid example.  This will work without virtual.

'virtual' has to do with a particular mechanism for implementing
polymorphism.  It says that the object referenced has a (hidden)
pointer to a function address table and any call to the 'virtual'
function has to use that pointer.  'static' say to ignore the
object instance even if there is one; only the class is
significant.  Thus there is a definitional conflict.  The two
qualifiers can not be combined without creating a logical
contradiction.

max@mtew.isa-geek.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Uzytkownik "Samee Zahur" <samee.zahur@gmail.com> napisal w wiadomosci
news:1113988855.827632.296990@o13g2000cwo.googlegroups.com...
> In a recent post in comp.lang.c++ I came to know that static member
> functions can never be virtual. So I am wondering why this restriction
> is in place ... although it usually makes more sense to call static
> functions like this : cls::fun() : it *can* also be called like this
> :obj.fun(): - with the same effect. So, couldn't the compiler use
> runtime resolution of the version function of the function to call when
> the second form is used with obj of type cls&  ?? That is, if fun was
> declared as virtual static fun(...) in cls. Why isn't anything like
> this allowed? The run-time type would then determine the set of static
> variables the function is allowed to use.
>
> Samee
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

This problem is more general. Since I started using C++, I have always felt
that it lacks virtual data. Consider the following example:

Class X { virtual int x; };

You cannot have anything like this under C++, but you can simulate it:

Class X { virtual int &x(void) = 00; };

The same solution applies to static functions as well:





Class X {

typedef int some_fun(int);

virtual some_fun *call_fun(void) = 0; } *pX;

.

Int x(pX->call_fun()(00));

Although it is not nice, it works.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> In a recent post in comp.lang.c++ I came to know that static member
> functions can never be virtual. So I am wondering why this restriction
> is in place ...

Samee, search comp.lang.c++.moderated for "static virtual". Take a look at
the discussion on March 25, 2005.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]