Sign in to follow this  

Another smart_ptr question - pass by value or ref?

This topic is 3628 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Perhaps you could enlighten me? Which is more efficient?
// obj is an object with many datamembers, costly to perform a copy when passing by value
boost::shared_ptr<bigObject> obj( new bigObject );

// Is this the same cost as using bigObject* as a function argument, ie passing by Pointer
void funcPassByValueOfPointer( boost::shared_ptr<bigObject> b );

// does this make sense or pointless?
void funcPassByRef( boost::shared_ptr<bigObject>& b);



Or do i need to use boost::ref, and how is that implemented? Thanks S

Share this post


Link to post
Share on other sites
Surely when passing by value, large objects are much slower by value than by ref-to-const since they invoke the implicit copy constructor, replicating the object and every datamember.

However, passing a pointer is as fast as passing by ref since only the address is passed, so is this also the case with smart pointers?

I imagine they are a little slower than normal pointers, since they have the reference count to increment.

Share this post


Link to post
Share on other sites
The point of boost::ref is pretty well explained in the documentation:
Quote:
Boost.Ref
The purpose of boost::reference_wrapper<T> is to contain a reference to an object of type T. It is primarily used to "feed" references to function templates (algorithms) that take their parameter by value.

To support this usage, boost::reference_wrapper<T> provides an implicit conversion to T&. This usually allows the function templates to work on references unmodified.

Share this post


Link to post
Share on other sites
Do you really need access to the smart-pointer? Why not pass a reference of the contained object instead?


void funcPassByRefOfObject(const bigObject& b);

boost::shared_ptr<bigObject> obj(new bigObject);
funcPassByRefOfObject(*obj)



[Edited by - dalleboy on January 5, 2008 4:17:42 AM]

Share this post


Link to post
Share on other sites
That entails "trusting" the function that's being called. The definition of "trust" is that someone is able to screw the pooch; in this case, by taking the address of your reference and storing it somewhere.
I would argue that unless this is really time critical, it's better (at least by virtue of being less potentially confusing) to pass the smart pointer by value.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jan Wassenberg
I would argue that unless this is really time critical, it's better (at least by virtue of being less potentially confusing) to pass the smart pointer by value.


This would imply that you have control over the function's signature. And if you do, then it's preferable to use a 'passing style' which correctly represents ownership:
  • By shared-pointer when the ownership is shared by both the caller and the called function.
  • By reference when the caller keeps exclusive ownership.
  • By auto-pointer when the called function receives exclusive ownership.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sc4Freak
boost::shared_ptr is uaually also 4 bytes larger than a regular pointer, so that may be something to take into consideration.


Small enough for me - Thanks

Share this post


Link to post
Share on other sites
Quote:
This would imply that you have control over the function's signature. And if you do, then it's preferable to use a 'passing style' which correctly represents ownership:

That sounds reasonable if you're the sole developer in a smallish project, but looks to break down under real-world maintenance.
It's unlikely that every corner of the codebase uses these semantics, so the rule may not be clear to junior coders. What's to prevent them from taking the address and storing it? Writing a "if you use & on this parameter, you will be shot/fired" comment in all of these spots would be tiresome. Sure, they could still store ptr.get(), but at least those spots can be found, unlike operator&.

Share this post


Link to post
Share on other sites

This topic is 3628 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this