Proper way to pass a pointer? c++

Question

I have a simple question that I am not 100% sure on.

Let us say I have a Entity class, that handles objects on the screen. Let us say the Entity class has two float variables, 'x' and 'y' (aka coordinates). Also let us say the entity I am passing has already been declared and is in memory.

I have another class that handles camera movement. It requires an entity to center on. The entity that it is centered on can changed, so I need to use a pointer here I believe. The only thing I do here is grab the X and Y variables when needed. Nothing is changed here.

I've defined it as

void StarField::ChangeFollowEntity(Entity* newFollowEntity) {
    followEntity = newFollowEntity;
}

where followEntity is also an Entity class. I would call ChangeFollowEntity(..) to change the entity. Is this actually correct?

I've also seen however this:

void StarField::ChangeFollowEntity(Entity newFollowEntity) {
    followEntity = &newFollowEntity;
}

In both cases followEntity is defined as Entity* followEntity; .. What does the second example exactly do here? From what I understand, & would typically be used as a reference type. Maybe it is incorrect to do to begin with.

I am pretty sure I shouldn't be using a reference in this case because the followEntity changes, which references I believe cannot change and must be defined.

So my question is, is my first example correct and the right way to do it? What does the second example do exactly?

In the order asked, Yes, and dangles a pointer likely-later to be dereferenced and invoke *undefined behavior*. — WhozCraig, Jul 17 '15 at 21:05
Does someone want to address his comment about whether a reference would work? — Barmar, Jul 17 '15 at 21:06
(const) reference should also work. `void StarField::ChangeFollowEntity(const Entity& newFollowEntity)` — Non-maskable Interrupt, Jul 17 '15 at 21:09
If you use & in a declaration you get a reference, but In the `followEntity = &newFollowEntity;` case & takes the address of newFollowEntity giving full-on pointer behaviour. followEntity is assigned the address of newFollowEntity. This usage is (partially) correct within the bounds of the function, but ends in disaster as already documented in the answers as soon as the function returns. — user4581301, Jul 17 '15 at 21:15
For safety, I'd recommend wrapping `Entity*` a bit differently and use a [std::shared_ptr](http://en.cppreference.com/w/cpp/memory/shared_ptr). Used correctly, shared_ptr prevents the entity from being destroyed while the camera is using it. — user4581301, Jul 17 '15 at 21:16

user007 · Accepted Answer · 2015-07-17T21:17:27.900

In your second version ::

void StarField::ChangeFollowEntity(Entity newFollowEntity) {
    followEntity = &newFollowEntity;
}

You pass the newFollowEntity by value, so when your function is called from main or from where ever! A copy of the object is made (using the copy constructor) and sent to the function ChangeFollowEntity, and after the completion of the execution of the function, your followEntity has the address of the COPY of the object, which gets destroyed after the completion of the function call, so your pointer followEntity is left dangling, which is undefined behavior if you access any entity using the followEntity

First is the correct way to do it!!

score 1 · Answer 2 · edited May 23 '17 at 11:43

What does the second example exactly do here?

Your second example creates a Entity newFollowEntity which only exists for the duration of that function call.

The address of that variable is stored, and then the variable is destroyed, leaving a dangling pointer.

That's bad.

I am pretty sure I shouldn't be using a reference in this case because the followEntity changes, which references I believe cannot change

You can use a reference in this case. A referenced object can be changed - you are probably recalling that a reference cannot be reassigned.

score 1 · Answer 3 · answered Jul 17 '15 at 21:05

The second example does the following:

When the function is called a new Entity object newFollowEntiry is created and whatever is passed into the function is used to construct it
Then an address of that local stack based object is taken and assigned to followEntiry to be stored presumably.
When the function execution is complete newFollowEntiry is destroyed
The folowEntity pointer is now pointing at a location in stack where there is not Entity object anymore.
BUG

Proper way to pass a pointer? c++

3 Answers3