# 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.

## 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 on other sites

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 on other sites

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

'wat' indeed.

##### 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 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 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 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 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.

1. 1
Rutin
29
2. 2
3. 3
4. 4
5. 5

• 13
• 13
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632961
• Total Posts
3009489
• ### Who's Online (See full list)

There are no registered users currently online

×