Re: Inline destructors and construtors
* James Kanze:
On 30 jan, 12:28, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
I'm not sure what "to be called virtually" means. I've
never seen the expression in any serious technical
literature
Ah, terminology!
Always fun!
Isn't it:-).
Well, the *international C++ standard* ISO/IEC 14882 uses the
term "virtual call" in two places.
Interesting. Does it define it, or just use it? (If the
latter, I would consider this a defect.)
The C++ standard is, IMHO, "serious technical literature"... ;-)
Obviously, I haven't memorized it completely:-). The full
explination of what happens when you call a function, if the
function happens to be virtual (in the static type) speaks of
resolution against the dynamic type, which is fairly precise.
For some strange reason, I supposed that they would be
consistent in their use of terminology:-).
The original Smalltalk view is very clear on the effect of a
virtual call. When there is a source code call of a method
with signature M on an object O, and the method M is virtual
in the statically known type of O, the execution effect is as
if a search for M starts in the most derived class of O's
dynamic type. The search for M goes upward all available base
class chains, in any order, until an M definition is found
(the order doesn't matter because C++ guarantees that there
will be only one M reachable in this way, although higher up
there may be more). The found M is called with a pointer to O
as the 'this' pointer.
I'm a bit confused about this. First you speak of Smalltalk,
then C++.
You should be confused, but not because of the presence of two language views.
Rather, you should be confused because in the above I forgot to add the
necessary qualifications, i.e., because above is wrong...
Namely, there should be noted that that a base class B (and so on recursively in
that tree) is only searched if M is virtual in B.
Argh.
The price of being precise.
In Smalltalk, IIRC, there can't be any ambiguity
because Smalltalk doesn't support multiple inheritance. And
IIRC (admittedly, a very big if), all functions in Smalltalk are
virtual. (Actually, IIRC, Smalltalk doesn't have functions,
only methods. And you can't call a method; you send a message
to an object. But I've never actually used Smalltalk, so none
of this is fixed in my mind like it is for C++.)
Uhm, mixture. "no ambiguity": right, but with reference to what? "all virtual":
right, even down to basic arithmetic primitives. "methods not functions": bull,
terminology. "can't call method": bull. "send message": just a conceptual view.
PS: Yeah, I know you know what a virtual call is, even if you
disagree with the standard's terminology (as do I for some
other terms). The explanation above is for the benefit of
other readers -- not all are aware of the Smalltalk view.
To tell the truth, I'm not that familiar with it either.
In that case, I recommend the old Smalltalk-80 series of books by Goldberg &
Robson, and especially the short & sweet introduction (just a few paras) in the
first one. Although the book 2 or 3 story of HP's (or was it Tectronix?) efforts
to implement a bitmapped display on a vector terminal is hilarious. As far as I
know only 3 books were published, although 4 were planned.
It's interesting to note that some GUI features described there have still not
full support in Windows...
Cheers, & hth.,
- Alf