"this" pointer

[Coltrane]

how does a member function obtain the "this" pointer?
I thought it was past into a function via the stack. Is this correct?

thanks

john

 

[Victor Bazarov]

how does a member function obtain the "this" pointer?
I thought it was past into a function via the stack. Is this correct?

Stack, register, whatever. It doesn't matter how it gets there, really.
The 'this' pointer in a non-static member function is what's known as
"the hidden argument". We don't know how that argument arrives to the
function, we only know that it does.

If you need the implementation details, look at the assembly produced by
your compiler. Or read "Inside the C++ Object Model" by Lippman.

V

 

[Coltrane]

Stack, register, whatever.  It doesn't matter how it gets there, really..
  The 'this' pointer in a non-static member function is what's known as
"the hidden argument".  We don't know how that argument arrives to the
function, we only know that it does.

If you need the implementation details, look at the assembly produced by
your compiler.  Or read "Inside the C++ Object Model" by Lippman.

V

thanks,
I was asked this on an interview and I thought it was on the stack but
I also thought it was implementation specific.
thanks again
john

 

[Pascal J. Bourguignon]

how does a member function obtain the "this" pointer?
I thought it was past into a function via the stack. Is this correct?

Conceptually, yes, via the stack.

In practice, the compilers may choose a different ABI, and pass it
thru a register (like for the other parameters), but this is
implementation specific detail you shouldn't care about.

 

[Coltrane]

Interview for what type of job, out of interest? Just wondering why they
might have asked the question. I guess if it was a job programming
compilers, then it might make sense to ask...

Stu

It was for a financial firm. they wanted a "C++ expert".
I was surprised they asked it. I remember when I first learned C++
back, about 20 years ago, that it was on the stack at least for a
microsoft compiler. I also seem to remember that it was compiler
specific. Well it doesn't matter now, I didn't get the job.

thanks
john

 

[Victor Bazarov]

It was for a financial firm. they wanted a "C++ expert".
I was surprised they asked it. I remember when I first learned C++
back, about 20 years ago, that it was on the stack at least for a
microsoft compiler. I also seem to remember that it was compiler
specific. Well it doesn't matter now, I didn't get the job.

thanks
john

And you think that particular answer was the contributing factor for
your not getting that job. Do you know what answer they were looking
for? Of course, it is not likely that one answer tilted the balance
against you. When people are looking for an "expert" in anything, they
are usually concerned more with the attitude than with a particular set
of knowledge bits. An expert IMO doesn't necessarily have the final
[and correct] answer to any question.

V

 

[osmium]

It was for a financial firm. they wanted a "C++ expert".
I was surprised they asked it. I remember when I first learned C++
back, about 20 years ago, that it was on the stack at least for a
microsoft compiler. I also seem to remember that it was compiler
specific. Well it doesn't matter now, I didn't get the job.

thanks
john

And you think that particular answer was the contributing factor for your
not getting that job. [?] Do you know what answer they were looking for?
Of course, it is not likely that one answer tilted the balance against
you. When people are looking for an "expert" in anything, they are
usually concerned more with the attitude than with a particular set of
knowledge bits. An expert IMO doesn't necessarily have the final [and
correct] answer to any question.

One good reason for asking is to see how the applicant acts when he gets
flustered. Does he fall to pieces? Make something up? Critique the
question and say "Why do you ask?"

 

[Juha Nieminen]

Conceptually, yes, via the stack.

In practice, the compilers may choose a different ABI, and pass it
thru a register (like for the other parameters), but this is
implementation specific detail you shouldn't care about.

Is taking the address of the 'this' pointer valid?

 

[robertwessel2]

  Is taking the address of the 'this' pointer valid?

No it's not. Nor may you assign to it.

 

[Victor Bazarov]

No it's not. Nor may you assign to it.

Those requirements are enforced by the language, and in no way do they
prove or disprove that the value of 'this' is passed on the stack or
otherwise. 'this' is an expression that yields an rvalue, I suppose.

V

 

[James Kanze]

Stack, register, whatever. It doesn't matter how it gets
there, really. The 'this' pointer in a non-static member
function is what's known as "the hidden argument". We don't
know how that argument arrives to the function, we only know
that it does.

Formally, it's not even an argument. Although I can't imagine
how you'd implement it otherwise, all the standard requires is
that it be present once you're in the function. (Practically,
of course, all the implementations I know pass it as a hidden
first argument, using the same conventions that they would for
any other argument. Why, I don't know---on an Intel processor,
I'd pass it in EBX, even though any other argument would be
passed on the stack, but the Intel compilers I have access to
don't do that.)

If you need the implementation details, look at the assembly
produced by your compiler. Or read "Inside the C++ Object
Model" by Lippman.

And don't forget that neither exhausts all of the possibilities.

 

[James Kanze]

On Aug 27, 9:04 am, Stuart Golodetz

[...]

It was for a financial firm. they wanted a "C++ expert". I
was surprised they asked it. I remember when I first learned
C++ back, about 20 years ago, that it was on the stack at
least for a microsoft compiler. I also seem to remember that
it was compiler specific. Well it doesn't matter now, I didn't
get the job.

Maybe luckily. Companies that ask that kind of question
generally don't know what they want or need, and are generally
confused elsewhere as well. Which doesn't make working for them
very pleasant.

If it makes you feel better, I was once rejected for a post
because of a similar sort of thing: the question was "what does
the keyword static mean?" and the answer they were looking for
was "not on the stack". They took the fact that I gave a twenty
line answer explaining different meanings in different contexts
as an indication that I didn't really understand C++.

Don't worry about it. Not all companies are that stupid.

 

[James Kanze]

No. Formally, it's a value, not an object, so it isn't
"passed", any more than the constant 42 is passed when you use
it. In both cases, it's up to the compiler to ensure that you
get the right value.

And of course, it also depends on what you mean by "stack".
Since the language supports recursive functions, all parameters
and local variables can be thought of as being on a stack,
abstractly. Practically, however, when people speak of "the
stack" (rather than "a stack"), they mean the machine stack.

Is taking the address of the 'this' pointer valid?

No. It's a value, not a variable or an object. (In C++ terms,
an rvalue, but for some reason, the C++ standard describes it in
C terms: a non-lvalue.) It has no address. (An rvalue only has
an address if it has class type. Dixit the standard---I've
worked on systems where doubles were actually in memory.)

 

[James Kanze]

Those requirements are enforced by the language, and in no way
do they prove or disprove that the value of 'this' is passed
on the stack or otherwise.

They don't say anything about how the compiler implements it,
no. But in one very real sense, "this" can't be "passed", on
the stack or otherwise, because it doesn't exist until you're in
the function. What the compiler passes is some interal
information that is uses to evaluate the value.

'this' is an expression that yields an rvalue, I suppose.

Yep. And since it has pointer type, the usual rules for
built-in operators apply: you can't use it in any expression
that requires an lvalue. (On the other hand, something like
"this + 1" is perfectly legal. I'd have some doubts concerning
the sanity of the programmer who used it, however.)

 

[robertwessel2]

Formally, it's not even an argument.  Although I can't imagine
how you'd implement it otherwise, all the standard requires is
that it be present once you're in the function.  (Practically,
of course, all the implementations I know pass it as a hidden
first argument, using the same conventions that they would for
any other argument.  Why, I don't know---on an Intel processor,
I'd pass it in EBX, even though any other argument would be
passed on the stack, but the Intel compilers I have access to
don't do that.)

As one example, 32 bit MSVC (by default) uses the "thiscall"
convention for non-vararg member functions, where the “this” pointer
is passed in ECX. For vararg member functions, it uses the more
conventional stack based convention ("cdecl"), and passes “this” as an
implied left-most parameter (IOW pushed on the stack last in the
typical right-to-left calling convention).