What is the etymology of the keyword "virtual"?

In D&E, Stroustrup mentions the name "virtual" is borrowed from Simula, but doesn't go into more detail. How does the word "virtual" connect to dynamic dispatch? What is "virtual" about virtual functions and the virtual table, or virtual inheritance?

Thanks!
Last edited on
Maybe because a virtual function offers a level of indirection relative to the code that will actually execute, similar to how "virtual memory" presents to the program a flat address space that can be mapped to various regions of physical memories. That in turn reminds me of the concept of "virtual image", which is the apparent image of a real object shown to an observer as they look through an optical device, such as a mirror or a lens. The lens may make the person appear upside down and very close, but in fact they're right side up and far away.
It kind of means "acts as if" (possessing the virtues/qualities of the real thing).
Virtual memory "acts as if" process memory is a flat contiguous space.
A virtual drive "acts as if" it's a real drive.
A virtual function "acts as if" it's part of the called-upon type.
I can't find a first-hand source, so I'm not sure if this directly answers your question as to why the word "virtual" was used, but here is a section that essentially describes it.
https://www.cs.tufts.edu/comp/150FP/archive/kristen-nygaard/hopl-simula.pdf
We had seen that the class/subclass facility made it possible to define generalized object classes, which could be specialized by defining subclasses containing additional declared properties. However, the concatenation mechanism was not quite flexible enough for adding details to the operation rules. Something like procedure parameters still seemed to be needed for classes.

As discussed in Section 2.3.3 the ALGOL-like call-by-name parameters were out of the question for reasons of security and storage allocation strategy: the actual parameter could be lost during the lifetime of an object. The problem then was to find a name parameter-like mechanism that would guarantee a safe place for the actual parameter. After much trial and error we hit on the virtual quantity concept where the actual would have to be declared in the object itself, but at a deeper subclass level than that of the virtual specification. Now generalized objects could be defined whose behavior pattern could be left partly unspecified in a prefix class body. Different subclasses could contain different actual procedure declarations.

The implementation efficiency of virtual quantities was good, since no change of environment was needed to access a virtual from within the object. Unfortunately we chose to model the virtual specifications after the parameter specifications of ALGOL, which meant that the parameters of a virtual procedure had to be run time checked.

So in this sense, "virtual" uses the meaning of "nearly, almost" in the dictionary, i.e. a virtual specification -- the specification is almost complete, but the "behavior pattern could be left partly unspecified in a prefix class body".

[Side note -- I'm not sure if "virtual inheritance" as its known in C++ (to solve the "diamond problem") is a feature in Simula. My guess is that Stroustrup used that just because virtual was already a keyword, and using virtual inheritance involves a lookup to get the shared base class, similar to virtual functions. Not sure, though.]
Last edited on
Thanks @Ganado, that's what I was looking for. Thanks also to @dutch and @helios as well, both responses definitely helped me gain some intuition.
The lens may make the person appear upside down and very close, but in fact they're right side up and far away. 
That has nothing whatsoever to do with the optics concept of a virtual image, Carol. Your physics is as bad as your grammar.
Topic archived. No new replies allowed.