not "this" again

[aden]

I have read the years-old threads on this topic, but I wanted to
confirm what they suggest. . .

Can the this pointer EVER point to a type different from the class that
contains the member function that the this pointer is being used in?
That is, is the type of the this pointer always determined entirely
syntactically (and never dynamically)?

Example: if a member function is invoked on an object of class Apple
(appleobj.drip_it() ), and that function uses the scope operator to
call a function in the superclass Fruit (Fruit::drip_it() ), does the
keyword this in Fruit::drip_it() point to a Fruit object or an Apple
object?

There are two reasons that I am bothering to ask this question when I
am pretty sure I know the answer. (The answer is that this is always
statically bound, its type determined entirely syntactically.) The
first reason is that it would be cool if this were dynamically bound,
as it would allow derived-class functions calls on non-virtual methods,
which would probably screw things up royally but would also extend rtti
possibilities in intuitive ways.

The second reason I ask is that a number of resources on the topic are
ambiguous. They quote the C++ standard to the effect that this is
always of type K* when it appears in a function within the class K. But
they also say that this points to whatever object "the function is
invoked on," which isn't entirely clear but seems to leave open the
possibility that a function could be invoked on an object in a
subclass.

Addendum: Given the above situation--where an Apple object calls a
Fruit method--how would you from within the Fruit method
Fruit::drip_it() call another Fruit method that was virtual and
overridden in Apple? If, within Fruit::drip_it() you call
Fruit::suck_it() (defined virtual), will the compiler create code that
uses the lookup table for the this object (in this case, an Apple
object), or will it use the scope operator and call the suck_it()
routine within Fruit?

Thanks for your consideration. Regards,

**** *** ****
A d e n
**** *** ****

[Alf P. Steinbach]

* ad**@who.net:

The static type of 'this' is statically determined.

The dynamic type of 'this' is dynamically determined.

Cheerio,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[aden]

Thank you for your succinct and appropriate response.

But wouldn't it make sense/be useful for "this" to "track" the dynamic
type of its object? Then, there would be a (useful) difference between
this->do_it() and just do_it(), since the "this" version would call a
method in the (dynamic) class type of the "this" object (which might be
a subclass of the current class), while the non-this version would just
call the current class's method. Maybe I'm itching for a language in
which all methods are virtual, but this seems like a worthwhile
consideration.

The advantage of such an implementation would be that "this" would
cease to be a relatively empty keyword and would serve more of a
purpose. Further, it would conform in an interesting way to its
standard English usage, where it refers to an object in all of its
particularity and not just to an object as determined by its context.

What would be the disadvantage? More look-up tables, I suppose, and
hence inefficiency at run-time.

Cheers,

**** *** ****
A d e n
**** *** ****

[Julián Albo]

ad**@who.net wrote:

Can the this pointer EVER point to a type different from the class that
contains the member function that the this pointer is being used in?
That is, is the type of the this pointer always determined entirely
syntactically (and never dynamically)?

Example: if a member function is invoked on an object of class Apple
(appleobj.drip_it() ), and that function uses the scope operator to
call a function in the superclass Fruit (Fruit::drip_it() ), does the
keyword this in Fruit::drip_it() point to a Fruit object or an Apple
object?

You seem to mix two concepts: the type of the pointer and the type of the
thing it points to.

The type of the pointer at compile time determines which member functions is
used. If the member functions is virtual, the result is to use the thing
pointed to, by using a virtual function table or whatever other way the
compiler uses to implement virtual functions, to see at runtime where is
the function to be used.

And in case the funtion used is in a derived class, this points to an object
of this class, but of course in that case this class is the class of this.

--
Salu2

[Pete Becker]

ad**@who.net wrote:

Thank you for your succinct and appropriate response.

But wouldn't it make sense/be useful for "this" to "track" the dynamic
type of its object? Then, there would be a (useful) difference between
this->do_it() and just do_it(), since the "this" version would call a
method in the (dynamic) class type of the "this" object (which might be
a subclass of the current class), while the non-this version would just
call the current class's method. Maybe I'm itching for a language in
which all methods are virtual, but this seems like a worthwhile
consideration.
If you want to decorate your code with this-> everywhere, feel free. But
please don't try to impose that verbosity on everyone else. <g>

To call the version of a function defined in your class use
ClassName::do_it().

The advantage of such an implementation would be that "this" would
cease to be a relatively empty keyword and would serve more of a
purpose.

I'm sure 'this' isn't feeling underutilized. There's no need to give it
more to do.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Julián Albo]

ad**@who.net wrote:

The advantage of such an implementation would be that "this" would
cease to be a relatively empty keyword and would serve more of a
purpose. Further, it would conform in an interesting way to its
standard English usage, where it refers to an object in all of its
particularity and not just to an object as determined by its context.
What would be the disadvantage? More look-up tables, I suppose, and
hence inefficiency at run-time.

The disadvantage is that this way is not an implementation of C++, is a
different language.

--
Salu2

[James Aguilar]

If you want to call the statically typed method, just add
"<static_class_name>::" in front of the method call. Most of the time
you mean to call the dynamic one, so this doesn't come up very often.

[aden]

James,

This confuses me again when I thought it was clear.

If a Circle object calls a method of class Shape, "Shape::prep()," and
there is a function call in Shape.prep() that uses "this," (implicitly
or explicitly, "this->draw()"), then the static-typed method will be
called, (right?), namely, the method Shape.draw(). (Unless Shape.draw()
is virtual, in which case the dynamic reference gets used.) When
calling a non-virtual method, there is no need to use
<static_class_name>:: with the implicit "this" in the method call. It
will resolve statically anyway. No?

**** *** ****
A d e n
**** *** ****

[Alf P. Steinbach]

* ad**@who.net:

This confuses me again when I thought it was clear.

Adding 'this->' to the left of a member function call doesn't do anything
(unless the call is ambigious and the 'this->' happens to disambiguate).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[James Aguilar]

Oh, I see what you are saying. So you want this->methodname() to call
the right method even if the method is not virtual? Well, that would
kind of not do what this-> is supposed to do and would very much break
backwards compatibility. I'm also not sure that it is useful: if you
want a virtual method, just make it virtual.