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;

By default, pass by const reference, unless you want to write to the original variable also, then pass by reference. Unless that parameter is optional, then pass by pointer.

Unless you want a copy, then pass by value.

If the variable is already in a shared pointer, then pass by const reference to shared pointer. Unless you want to modify the variable, in which case you pass by reference to shared_ptr. Unless you want a copy of the shared_ptr (which doesn't copy the variable the pointer points to), then pass a shared_ptr by value.

Shared pointers delete the variable they point to, after no more of the shared_ptrs are left alive. To protect yourself from these kind of mistakes, a simple trick is to never create a shared_ptr manually, but instead use std::make_shared() for creating shared_ptrs.

But in this situation, all you're wanting to do is make 'NBody::Renderer' accessible to that function. So pass by const reference, if read-only, or regular reference, if read-write. There is no need for a smart pointer to be used here at all.

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.

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.

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?

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.