Thread: Scope of references?

Did a little Googling on this but couldn't find anything definitive. Is it safe to do something like

Code:

void MyClass::myFunc()
{
  my_type_t &foo = some_obj->get_member_reference();

  store_for_later(&foo);
}

Then at some pointer later in execution, another function uses the pointer passed to store_for_later.

O_o

That has nothing to do with the scope of references.

That has everything to do with the lifetime of objects.

Now, references can be used to extend the lifetime of an object. (An example would be storing the return of a function in a named constant reference.)

However, here you may be doing the same thing as just returning a pointer to a local object. In this way, references and pointers are no different, the lifetime of the object lives only as long as you guarantee the object lives; any handles to that object, pointer and references, can easily outlive an object with code like that.

Yes, I am aware that this is a member class. We just don't know how long the `MyClass' instance lives versus "how long after" `store_for_later' may attempt to use the reference.

In short, it is perfectly safe in that the underlying object may live past its use from such a reference, but it is extremely error prone so it is highly recommended that you not do it.

A better solution for when this case comes up: shared smart pointers to an allocated form of the member to be used.

Soma

Originally Posted by laserlight

Moved to C++ programming forum.

Yea, sorry. Didn't notice I was in the C forum when I posted.

Originally Posted by laserlight

I suggest that you post the smallest and simplest program that demonstrates your idea since whether or not this is okay would depend on things like whether or not some_obj exists at that point and what does get_member_reference actually return, and what does store_for_later (and any related function) actually do. (EDIT: also, knowing the bigger picture of what you are trying to do could allow us to suggest a better (and safer) way of doing things.)

In my case, some_obj exists for the lifetime of the program. I tried to be descriptive with the names. get_member_reference just returns a reference to some member var of some_obj. store_for_later just saves the pointer passed to it to be used in some fashion at another time.

As for the bigger picture, hopefully this description makes sense. Say I have a vector of pointers all initialized to null. store_for_later stores the passed in pointer into the vector. At some time later, the vector is looped through and each non-zero stored pointer is dereferenced. Assuming some_obj always exists, it sounds like I should be safe to do this. I wasn't sure if saving the address of the foo reference was the same as saving the address of the member var since foo is in local scope. For example, if foo was a pointer and it was initialized with get_member_pointer, I know I wouldn't be able to save foo's address to be used later because I know that address would go out of scope once myFunc returned.

In my case, some_obj exists for the lifetime of the program.

If you take responsibility to guarantee this, the pointer to the member is fine.

The question is, do you want to take that responsibility? What if you, for example, refactor the code later so that `some_obj' doesn't live "forever". What then?

I wasn't sure if saving the address of the foo reference was the same as saving the address of the member var since foo is in local scope.

You aren't saving the address of the `foo' reference.

(In fact, you can't save the address of any reference, here being C++ references, without some really wonky code which doesn't really work.)

You are saving the address that the reference references. That is how references work.

The code you have is the same as:

Code:

store_for_later(&some_obj->get_member_reference());

The reference is now not involved; is this valid in your use? Does it honor the lifetime of `some_obj'?

For example, if foo was a pointer and it was initialized with get_member_pointer, I know I wouldn't be able to save foo's address to be used later because I know that address would go out of scope once myFunc returned.

You could return the value of `foo'; that is closer to what you've done.

Soma

The problem with you describing what you're doing is that what you think about the code and what the code actually does might be different.