0

i don't understand, why the pointer front is pointing on the object berta (i know that anton and berta are created on the stack)

1 Hello* front;
2
3 void createHello() {
4   Hello anton("Anton");
5   front = &anton;
6 }
7
8 int main() {
9   createHello();
10  Hello berta("Berta");
11  front->body();
12}

1 class Hello {
2     Hello(const char* name) : name(name) {
3     out.print(name);
4     out.print(" ctor;");
5   }
6
7   ~Hello(){
8     out.print(name);
9     out.print(" dtor;");
10  }
11
12  void body () {
13    out.print(name);
14    out.print( " body;");
15  }
16
17  const char* name;
18};

Output: Anton ctor;Anton dtor;Berta ctor;Berta body;Berta dtor;

out.print() is a simple function that prints an string on the monitor

I thought that will happen:

createHello() - registers are pushed on the Stack, return-address is pushed on the Stack

Hello anton("Anton") - object will be pushed on the Stack

front = &anton; pointer points on address from anton

esp - will be set to a position before the function call

Hello berta("Berta"); - object "berta" will be pushed on the Stack

front->body(); - prints Berta body; why the hell is this happening?

I mean the front pointer should point on different position in the Stack:

1.{lowerAddress}

anton <-front <-esp

return-address

registers

{higherAddress}

2.

anton <-front

return-address

registers

<-esp

3.

anton<-front

return-address

berta<-esp

So there should be just 2 possibilities: anton will be partly overridden or it still exists and berta is laying in a higher storage position. If anton will be partly overriden there should appear some rnd stuff for front->body. If anton will not be overriden then it should return "Anton body;".

Can you explain to me why that isn't happening? And instead berta overrides the object anton so that front points exactly on berta?

@Edit forgot *, so yeah front is a pointer

@Edit i would never program sth. in such a way - my university gave me this crap - idk how to solve it - yeah i just can say "hmm berta is created exactly on anton and overrides him" but i dont understand why - normally berta should be created on a higher address.

baxbear
  • 860
  • 3
  • 9
  • 27

1 Answers1

3

As soon as your call to createHello() returns, Anton goes out of scope and its destructor is called, hence your output:

Anton ctor;Anton dtor;

At this point, front is a dangling pointer.

Then you create Berta, which is pushed onto the stack in the same location Anton used to exist at, causing front to point at Berta.

If you used new to allocate Anton on the heap, Anton would persist through the life of the program or until you called delete.

Edit: As per Dale's comment, this behavior should be assumed coincidental. It would be unwise to write code that assumes Berta will always exist at the same address that Anton did.

Dan Bechard
  • 5,104
  • 3
  • 34
  • 51
  • 3
    I would only add "by accident". Returning a reference to a local variable is undefined behavior. The particular way in which your program will fail varies based on the compiler, the compile-time options, and the phase of the moon. – Dale Wilson May 14 '14 at 18:12
  • 1
    @DaleWilson As far as know, so long as nothing else is pushed to the stack between `createHello()` and the instantiation of Berta, Berta will always exist at the exact same memory address on the stack that Anton did. I would be interested in seeing an example of a case where this is not true. – Dan Bechard May 14 '14 at 18:15
  • Move the creation of berta before the call to createHello() and I guarantee that Berta and Anton will occupy different areas of memory, right? There is nothing to prevent the compiler writers from allocating stack memory as if you had done this -- it might even be more efficient because there would be no need to manipulate the stack pointer to create Berta -- which means that the compiler could optimize the code that way. The point is that a good proggrammer will not EVER take advantage of "the compiler probably does it this way" assumptions. – Dale Wilson May 14 '14 at 18:25
  • @DaleWilson While I agree that the assumption is extremely poor coding practice, I still disagree that any compiler's optimizer is going to switch the order of a function call and variable declaration. The whole point of optimization is to perform the same exact actions in a more efficient way, not to perform completely different actions because they are faster. – Dan Bechard May 14 '14 at 18:37
  • I have worked with compilers that allocated memory for all local variables at the time you entered a block (a single change in the stack pointer allocates the space). Of course you can't actually initialize berta until you hit the right place in the code, but there is a difference in allocating the space and calling the constructor. – Dale Wilson May 14 '14 at 18:39
  • @DaleWilson In either case, the OP is asking *why* this happens, not whether or not you recommend he use this code in production. I'll edit my answer to reflect the uncertainty of this coincidence though. – Dan Bechard May 14 '14 at 18:40
  • @Dan: I could easily picture an architecture where OS and compiler cooperate to create stack objects at *random* addresses, to avoid stack exploits... – DevSolar May 14 '14 at 18:57
  • @Dan i think i know what happens but not why - because berta should (as far as i know) be created on a higher address on the stack because after the function called and returned the return address and the registers are no longer visible on the stack (they still exist but the stackpointer is on a higher address) and anton lays above the return-address and saved registers(so he lays on a far lower address). Now i create berta so it can't be on the exact same position as anton. – baxbear May 14 '14 at 19:09
  • 1
    @baxbear You can print the value of `front` without dereferencing it to write the memory address to the console if you want to know for sure. – Dan Bechard May 14 '14 at 20:28