Jump to content
  • Advertisement
Sign in to follow this  
jdub

passing std::shared_ptr to a function?

This topic is 1877 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

I have this code which causes a strange error:

void NBodySim::DrawCSOutput(std::shared_ptr<NBody::Renderer> graphics)
	{
		try
		{
			graphics->SBatch->Begin();

			RECT destRect;
			destRect.left = 0;
			destRect.right = 256;
			destRect.bottom = 256;
			destRect.top = 0;

			graphics->SBatch->Draw(this->uavSrv, destRect);

			graphics->SBatch->End();
		}
		catch(std::exception e)
		{
			const char *wat = e.what();
			int i = 0;
		}
	}

//DrawCSOutput() is called like this:
this->sim.DrawCSOutput(std::shared_ptr<NBody::Renderer>(this->graphics));

//this is the graphics member variable:
Renderer graphics;

I have managed to fix the code by changing the function to take a weak pointer instead but I am wondering, how can I successfully pass std::shared_ptr<T> as an argument to a function?

Share this post


Link to post
Share on other sites
Advertisement

The problem with the code above is that after the function call, the shared pointer will end up with 0 references and destroy the object (as it is the ONLY shared pointer to own that object).

 

 

If you would like to pass in a shared_ptr but keep the object alive, store your member as a shared_ptr and then pass it in to the function like so:

void NBodySim::DrawCSOutput(std::shared_ptr<NBody::Renderer> graphics)
	{
		try
		{
			graphics->SBatch->Begin();

			RECT destRect;
			destRect.left = 0;
			destRect.right = 256;
			destRect.bottom = 256;
			destRect.top = 0;

			graphics->SBatch->Draw(this->uavSrv, destRect);

			graphics->SBatch->End();
		}
		catch(std::exception e)
		{
			const char *wat = e.what();
			int i = 0;
		}
	}

//DrawCSOutput() is called like this:
this->sim.DrawCSOutput(this->graphics);

//this is the graphics member variable:
std::shared_ptr<Renderer> graphics;

Share this post


Link to post
Share on other sites

        catch(std::exception e)
        {
            const char *wat = e.what();
            int i = 0;
        }

 

'wat' indeed.

Share this post


Link to post
Share on other sites

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

Share this post


Link to post
Share on other sites

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

It's easier to use intelisense with.

Share this post


Link to post
Share on other sites

 

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

It's easier to use intelisense with.

 

 

True, but there are also a few minor side effects.

 

First is that if the class overrides operator-> it will use that instead. This is a fairly rare thing, but something to consider.

 

Second is that it has the potential to cause some unnecessary trips to memory. Most optimizers will strip that away, but as this is the "General Programming" forum rather than "For Beginners", we should not be over-reliant on the optimizer. I've worked on several systems over the years (Nintendo DS, PalmOS, etc.) that when encountered would dereference the this pointer and follow it rather than use the information already loaded in registers.

 

 

My current studio includes it is in our programming style guide as a restricted practice. I flag it in code reviews as an error when I see it.

Share this post


Link to post
Share on other sites

 

 

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

It's easier to use intelisense with.

 

 

True, but there are also a few minor side effects.

 

First is that if the class overrides operator-> it will use that instead. This is a fairly rare thing, but something to consider.

 

 

If class X overloads operator->, that affects using the operator-> on a pointer to X?

Share this post


Link to post
Share on other sites

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

It's easier to use intelisense with.

 
True, but there are also a few minor side effects.
 
First is that if the class overrides operator-> it will use that instead. This is a fairly rare thing, but something to consider.
 
Second is that it has the potential to cause some unnecessary trips to memory. Most optimizers will strip that away, but as this is the "General Programming" forum rather than "For Beginners", we should not be over-reliant on the optimizer. I've worked on several systems over the years (Nintendo DS, PalmOS, etc.) that when encountered would dereference the this pointer and follow it rather than use the information already loaded in registers.
 

My current studio includes it is in our programming style guide as a restricted practice. I flag it in code reviews as an error when I see it.

As pointed out above, overriding -> has no effect on this.

Unless working on a platform where you must use a poor compiler, performing optimizations that the compiler can do for you trivially is premature optimization and should not be a major consideration in program style. A more reasonable objection is that it's verbose, and I think that's the real trade off here. Also using this-> has the advantage that it makes it easy to identify which variables are members.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!