The definition of Object above should be:
class Object {
public:
int a;
};
BTW, this program as is, may work fine, but the error is exactly the sort of thing that will come and bite you when you don't expect it.
Main Topics
Browse All TopicsIf in a class we store a pointer to an object and in its get
function return a reference to the object , in its set function take a reference to an object as input, is it going to fail under any condition?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
You wrote: "its set function take a reference to an object as input".
Who created this object? Who's responsible for deleting it? Is your own class suppose to adopt it? If so, you should make sure that:
1. It is heap allocated.
2. It will not be deleted by the part of the program that created it.
The possible error of someone taking the address of the object returned by get() and deleting it seems less likely to happen.
Some versions of set function:
X::SetObject(Object& obj);
X::SetObject(Object* obj);
I don't like using references to pass such objects. It is to easy to make one of stack, use the set function and get into trouble. Explicit use of pointers reminds me that I have to keep an eye on object ownership and lifetime.
I agree with comments above about taking ownership of objects in Set functions, pointers give you a better clue of what might happen to the object.
I also think the use of convention is very useful in these cases, for exaple we prefix functions that take ownership of an object (that is supposed to be heap allocated) with Adopt, so we would have:
X::AdoptObject(Object* obj)
just to give users of the class a further clue about what is expected.
The questioner doesn't say why he wants to do this, but maybe it is an efficiency thing. Scott Meyers talks about the ultimate futility of trying to avoid returning results by value in More Effective C++ (he also points out how Return Value Optimisation makes return by value more inexpensive than you might think).
Business Accounts
Answer for Membership
by: jasonclarkePosted on 1999-05-26 at 03:23:26ID: 1195215
Depends, you have to be very careful with lifetime and scope of objects when you do this kind of thing, for example:
class Object {
public:
};
class X {
public:
X() { thing = new Object; }
~X() { delete thing; }
Object* thing;
Object& getThing() { return *thing; }
};
main()
{
X* myx = new X;
Object& myThing = myx->getThing();
delete myx;
myThing.a = 2; // This could be very bad...
return 0;
}
In this example, the lifetime of the reference set up in the call to the get function is longer than the object that contains the pointer, and hence you have undefined behaviour when the reference is used after the object is destroyed.
It would be difficult to prevent this kind of thing with code, but it may be OK if you can enforce a suitable convention or if you know the circumstances in which the object is to be used.