Is this way of making a reference from a pointer safe ?Code:#include<iostream> int& foo(int* x) { return *x; } int main() { int x=0; foo(&x) = 5; std::cout<<x; // x turns out to be 5 return 0; }
Is this way of making a reference from a pointer safe ?Code:#include<iostream> int& foo(int* x) { return *x; } int main() { int x=0; foo(&x) = 5; std::cout<<x; // x turns out to be 5 return 0; }
Well, you could create a dangling reference that way. What if I did:
pointee& obj = foo(ptr);
delete ptr;
The reference is invalid.
I want to return a reference corresponding to a private member which is a pointer.
So, as long as the object is not 'delete'd, I'm safe ?
(I was worried about copies being made and the correct address not being written into... but that seems ok now)
For linked structures, I'm doing the implementation with pointers, but the interface does not need that complication.Originally Posted by whiteflags
The class would be easier to use that way.
Any better(trusty ) alternative ?
Sometimes it is necessary, though. Say you have a member variable that may need to be "repointed" after construction. You can't simply use a reference, and reverting to pointer syntax might detract from the rest of the code. In that case such a convention might prove useful...
Just use pointers. Dangling references aren't supposed to happen so I would remove the possibility altogether.
I'd say it's perfectly fine. Returning a pointer is no better; a dangling reference is no worse than a dangling pointer, and you don't want to the implementation details to define your interface.
However, to eliminate the possibility of dangling pointers or references, return a smart pointer.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
For linked structures, I'm doing the implementation with pointers, but the interface does not need that complication.
The class would be easier to use that way.Elysia, you should read the thread before making such strong claims.And for goodness sake, don't allow the caller to modify the value of the returned member. Return a const reference, and use a setter if it is necessary to modify it.
"I'm making a linked list" - "For goodness sake, make it a read-only linked list!"
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
I am referring to the example, which is a demonstration of what you should not do.
I did read the thread. Whatever manasij wants to actually do is of no concern to me.
If he/she posts code on the actual design, I'd offer the same advice if and only if I saw the same thing, and if it was relevant.
Sure it's better. If you have a dangling pointer and the API is clear to document which operations invalidate such returned pointers, then you know when to reassign them or let them fall out of scope. At least with pointers, you have the option of reassigning them. Either way, I agree, it doesn't really matter what manasij does since you could solve the problem by documenting it. Plus, it truly depends on who can use delete. Since this is a class, it would be reasonably safe if only the class would delete the x in int& foo(int* x); ...
To say that you should always return a pointer would be to say that vectors should not allow indexing.
Documenting when a references, pointers, or iterators become invalid is certainly important, but depending on the use case it may be appropriate to do more to prevent undefined behavior.
Yes, returning a reference should never be used to transfer ownership of an object.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Don't we have move for that...when needed ?Yes, returning a reference should never be used to transfer ownership of an object.
I'm just returning it to provide an interface tor linked structures' referenced node(s).