Is it best to return a class or a reference to a class?

[Tom]

If I have a container class that has a map member which stores pointers
to objects that have been created via the new operator and I have a
method that returns a entry in the map, would it be best to return the
entry as a dereferenced pointer so it becomes a class or return a
reference to the dereferenced class?

I believe that it would be best to dereference the class pointer
retrieved from the map and then send it back as a reference to the
caller. This would ensure that any manipulations to the returned class
would be reflected in the class stored in the container objects map?

It may be that the container class will be shunted around the
application and the data contained in it manipulated in various methods
and functions.

TIA,
Tom.

 

[F.J.K.]

If I have a container class that has a map member which stores pointers
to objects that have been created via the new operator and I have a
method that returns a entry in the map, would it be best to return the
entry as a dereferenced pointer so it becomes a class or return a
reference to the dereferenced class?

I believe that it would be best to dereference the class pointer
retrieved from the map and then send it back as a reference to the
caller. This would ensure that any manipulations to the returned class
would be reflected in the class stored in the container objects map?

It may be that the container class will be shunted around the
application and the data contained in it manipulated in various methods
and functions.

TIA,
Tom.

If you want to manipulate the returned data with the manipulation
taking effect on the original data object, you need to return either
references or pointers.

 

[Victor Bazarov]

If I have a container class that has a map member which stores
pointers to objects that have been created via the new operator and I
have a method that returns a entry in the map, would it be best to
return the entry as a dereferenced pointer so it becomes a class or
return a reference to the dereferenced class?

I believe that it would be best to dereference the class pointer
retrieved from the map and then send it back as a reference to the
caller. This would ensure that any manipulations to the returned
class would be reflected in the class stored in the container objects
map?

It may be that the container class will be shunted around the
application and the data contained in it manipulated in various
methods and functions.

Something doesn't add up. If you have a requirement to allow the
code that receives the [object or reference] to change the object
actually stored, then how can you return another object? Unless your
objects are wrappers (proxies), you copy the data from your storage,
the recipient changes the copy, nothing is changed in your storage.
I don't see that you have any choice.

Now, if you don't want to allow the recipient of your stored data
to manipulate it, you have a choice of either returning an object or
a reference to const. You need to decide whether it's worth copying
the object (if not, return a reference to const) or whether the other
party can try to hold onto the returned value which can change at
your own discretion. If it's important that the object reflected
the changes you make to it even if the third party holds onto the
returned "value", return a reference - the recipient will always have
the fresh version (although they might need to be notified that the
changes have actually occurred). If you specifically don't want to
let the changes propagate (the recipient gets a "snapshot" of the
value and not a "handle" to it), then return an object.

It seems that you haven't supplied enough information to answer your
question, or you just haven't thought of all possibilities yourself.

V

 

[Tom]

If I have a container class that has a map member which stores
pointers to objects that have been created via the new operator and I
have a method that returns a entry in the map, would it be best to
return the entry as a dereferenced pointer so it becomes a class or
return a reference to the dereferenced class?

I believe that it would be best to dereference the class pointer
retrieved from the map and then send it back as a reference to the
caller. This would ensure that any manipulations to the returned
class would be reflected in the class stored in the container objects
map?

It may be that the container class will be shunted around the
application and the data contained in it manipulated in various
methods and functions.

Something doesn't add up. If you have a requirement to allow the
code that receives the [object or reference] to change the object
actually stored, then how can you return another object? Unless your
objects are wrappers (proxies), you copy the data from your storage,
the recipient changes the copy, nothing is changed in your storage.
I don't see that you have any choice.

Now, if you don't want to allow the recipient of your stored data
to manipulate it, you have a choice of either returning an object or
a reference to const. You need to decide whether it's worth copying
the object (if not, return a reference to const) or whether the other
party can try to hold onto the returned value which can change at
your own discretion. If it's important that the object reflected
the changes you make to it even if the third party holds onto the
returned "value", return a reference - the recipient will always have
the fresh version (although they might need to be notified that the
changes have actually occurred). If you specifically don't want to
let the changes propagate (the recipient gets a "snapshot" of the
value and not a "handle" to it), then return an object.

It seems that you haven't supplied enough information to answer your
question, or you just haven't thought of all possibilities yourself.

V

The scenario is this

The original values to the map are created in the initial function of
the application. Further processing in various functions throughout
the application need to use the data in the map and sometimes actually
change the data held in the map.

Rather than have to extract the original objects in the map and replace
them when they are modified, it would be nice to simply retrieve a
modifiable version of the objects that reflect the changes in the
original without the need to have to delete the original and add the
new version or even replace the original with the newer version.

I think JFK has already provided the answer I had a feeling would be
the preferred which is to store/retrieve the pointer to the original
object so that any changes are indeed reflected in the objects stored
in the map.

Thanks,
Tom

 

[Victor Bazarov]

The scenario is this

The original values to the map are created in the initial function of
the application. Further processing in various functions throughout
the application need to use the data in the map and sometimes actually
change the data held in the map.

Rather than have to extract the original objects in the map and
replace them when they are modified, it would be nice to simply
retrieve a modifiable version of the objects that reflect the changes
in the original without the need to have to delete the original and
add the new version or even replace the original with the newer
version.

Or, perhaps you should give the object that owns the map to make the
changes necessary... Was it yesterday that I read about Law of Demeter
here? Or was it in a different newsgroup?... I don't remember. Check
it out, though.

I think JFK has already provided the answer I had a feeling would be
the preferred [...]

I am glad that his/her guess was right. Next time do give more thought
to the design and provide more information.

V

 

[Tom]

Or, perhaps you should give the object that owns the map to make the
changes necessary... Was it yesterday that I read about Law of Demeter
here? Or was it in a different newsgroup?... I don't remember. Check
it out, though.

<snip>

Although I agree with you that the Law of Demeter is correct, I think
you are missing the point here. LoD does not preclude the use of
databases/repositories or transport mechanisms and/or does not
interpret the database/repository or transport mechanism as the
"friend" or as a stranger.

The class that holds the map in this scenario is simply a container for
application data. The only purpose of it is to transport application
data around the application. Think of it similar to a shopping cart,
though that is not the use here but a good analogy, in that the
container holds various types of application data types in the same way
that a shopping cart can hold different inventory.

In this way it is both a friend and neutral, in that it is presents a
known interface to the application in order for the application to
store data in a retrieve data from using setter/getter methods. Other
than that, the application knows nothing about it.

The data classes contained in the class map are known application data
types which the application manipulates. Given that there is a need to
manipulate the data in various different points in the application and
and unknown quantity of the data, it serves well to store/retrieve
references/pointers to the data classes such that they can be
manipulated without the overhead of copy ctors or assignment operators.
The alternative would be to hold global arrays/maps/vectors/lists of
the data types which is not very nice to deal with.

Simply put I have created a container specific to the needs of my
application and as such it should be compared to using a std::map or
std::vector or any other std::container for that matter. LoD does not
preclude the use of such containers.

Thanks,
Tom.