Re: [reSIProcate] Minor point: passing shared pointers
SharedPtr is not a normal type -- it has special casting behavior.
Passing it by reference defeats its casting properties.
For example, if B is derived from A, a SharedPtr<B> can be passed by value to a formal parameter of SharedPtr<A>.
If you pass it by reference, it will not match.
Note that this is natural behavior for a pointer and un-natural
behavior for a class. Since SharedPtr is trying hard to be a pointer,
it gets to do this sort of trickery.
In conclusion, if there is a possibilty of polymorphism, pass SharedPtr by value.
david
On 9/13/05, Alan Stokes <alan@xxxxxxxxxxxxxxxxx> wrote:
There are fair number of places in the code where SharedPtrs are being
passed by reference, when actually const reference would be more
appropriate. For example DialogUsageManager.hxx has
void setMasterProfile(SharedPtr<MasterProfile>& masterProfile);
instead of
void setMasterProfile(SharedPtr<MasterProfile> const & masterProfile);
(You aren't going to modify my copy of the SharedPtr, only make your own copy of it.)
I came across this because I tend to make absolutely everything I can
const - and if I have a const SharedPtr I can't pass it to one of these
functions.
- Alan
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel