guthrie@miu.edu writes:
> ?? Then what is "static" about it?
>  In what sense is it class-wide, or any different than a normal member
> virtual function?

If I understand Fergus right, what's static about it is that it doesn't
require an object of that type to exist. The "static virtual" has to be
told about a type in some way, though, either by explicit scope
resolution

        my_class::function()

or by calling it with respect to a specific object:

        my_class        A, *B;
        A.function();
        B->function();

(Which of course does require an instance to exist, negating the
intended gain.)

Current (non-virtual) statics can be called the same ways. Basically it
just spares the requirement of creating an instance when wanting
polymorphism. There's also sometimes a run-time savings of about 1
instruction for going from object pointer to vtable pointer, but that's
minute.

> Of course one can design anything; but something that is static (in the
> current sense) if accessed through one syntax, and object-ive when
> accessed through another, seems confusing.

Am I right in assuming that by "static" you mean "statically typed"? The
word has too many meanings in C++.

If so, normal virtual functions do that too -- are also statically or
dynamically typed depending on how they're called -- so IMO that's not a
problem.

> I can't think of a design idea which it implements.

Now that IMO _is_ an important objection. Like the Yankee trader's
horse's second flaw, "He won't do nothin' once ye ketch 'im." There are
surely some designs that would go slightly easier with static virtuals,
but not in proportion to the cost of adding them IMO.

        Tom

--
tob@world.std.com
TomBreton@delphi.com: Author of The Burning Tower