[reSIProcate] Minor point: passing shared pointers

[david Butcher]

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 at alanstokes.org.uk> 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 at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050913/41270d3f/attachment.htm>