Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!att!dptg!ulysses!andante!alice!shopiro
From: shopiro@alice.UUCP (Jonathan Shopiro)
Newsgroups: comp.lang.c++
Subject: Re: virtual static class functions
Summary: Calling a virtual static function with an object yields runtime binding, calling it with a class name yields compiletime binding.
Message-ID: <10590@alice.UUCP>
Date: 17 Mar 90 21:16:59 GMT
References: <38579@cornell.UUCP> <10586@alice.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 42

In article <10586@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes:
- In article <38579@cornell.UUCP>, deb@svax.cs.cornell.edu (David Baraff) writes:
- 
- > Why can't static class functions be virtual? That is,
- > is there some reason why allowing static virtual class functions
- > would be bad? I can't see that the implementation would pose
- > any problems.
- 
- A virtual function implies run-time dispatching based on the
- type of the object used to call the function.
- 
- A static function implies that an object need not be supplied
- to call it.
- 
- If no object is supplied, how would the implementation determine
- which function to call?

The summary says it all.

Sample code:

	struct Foo {
		static virtual void f();
	};
	struct Bar : public Foo {
		static void f();
	};

	void zot() {
		Foo*  p = new Bar;
		Foo::f();       // calls Foo::f() (compiletime binding)
		p->f();         // calls Bar::f() (runtime binding)
	}

Note that there's similar syntax that allows you to call the ``wrong''
version of a non-static virtual function.

It's not obvious that this is worth doing, but it's certainly feasible.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Warren, NJ  07060-0908
		research!shopiro   (201) 580-4229