1

I have a player class that uses my DirectX Graphics class to create surfaces and draw sprites.

I am passing the graphics class as a pointer to the player class methodlike this:

**game.cpp**
m_pPlayer->Init(Graphics* graphics);

Inside the player class my Init method passes the pointer to another pointer method. Is there any benefit to creating another graphics pointer in the player class and copying the pointer argument instead?

So this:

**player.cpp**
m_pSurface->Init(graphics, m_width, m_height);

vs this:

**player.cpp**
m_pGraphics = graphics;
m_pSurface->Init(m_pGraphics, m_width, m_height);

I know that having a m_pGraphics pointer allows me to reuse the pointer again in the same class, such as my drawing method but I call the method in the player class anyway so can't I just keep passing the pointer over and over again?

ball
  • 39
  • 7
  • Yes, you can just pass it around. Copying will be slower, more memory and more code, so if you don´t need it... – deviantfan Nov 10 '14 at 10:14
  • 2
    These two snippets are absolutely equivalent. There is no reason whatsoever to prefer one over the other. Pointer copying is extremely cheap and is likely to be optimized anyway. Perhaps you are confusing `Graphics*` with `Graphics`. The latter should not be copied (you are probably not allowed to anyway). – n. m. could be an AI Nov 10 '14 at 10:46
  • Offtopic. Matter of class design. You probably don't want your player class to contain "Surface" or every other knowledge about "Graphics". And you probably want to use a constructor instead of "Init" method. Using raw pointers and pointers in general should be also reconsidered. – Ivan Aksamentov - Drop Nov 12 '14 at 16:09
  • The surface class is more like a sprite class but instead of loading an image it just fills the surface with colour, as the pong game only needs coloured rectangles for the paddles. Can you explain more on the constructor? I already have a constructor that initialised all my member variables and pointers to 0 or NULL. My init method sets the correct values such as width, height and position of the paddle. – ball Nov 13 '14 at 14:38

1 Answers1

0

This is just a matter of style and is unlikely to have any effect on performance. Copying pointers is very cheap and I would leave it to the compiler to optimize.

If player uses the Graphics object a great deal it would be reasonable to store a pointer in a member variable instead of passing it in all the time. It may make the member function signatures on player shorter which is good.

You do need to be sure that the member pointer to the Graphics object remains valid whenever it is used. Is it still the correct Graphics object and is it still alive? If you pass the pointer every time you might not have this complication.

Chris Drew
  • 14,926
  • 3
  • 34
  • 54
  • Thank you, this makes alot of sense. I could use the if(pointer==NULL) { return false; } to validate the pointer everytime. If copying pointers is efficient it looks like this is a good programming style to use. – ball Nov 10 '14 at 13:38
  • Yes, it is probably worth checking passed in pointers for null although it is better practice in C++11 to use `nullptr` instead of `NULL` because it has pointer type. Note that a `nullptr` check will not protect you against pointers to deleted objects. – Chris Drew Nov 10 '14 at 13:49
  • Note that copying raw pointers is indeed cheap, but copying around smart-pointers may or may not be. Using raw pointers is problematic in large programs, so things like ``std::shared_ptr``, ``std::unique_ptr``, ``Microsoft::WRL::ComPtr``, etc. help ensure proper ownership and cleanup of resources. You can resolve this by passing the smart-pointer by constant reference (i.e. ``const &``) or passing raw pointers where you are not going to take ownership of the pointer. See [DirectX Tool Kit](http://go.microsoft.com/fwlink/?LinkId=248929) for examples of this. – Chuck Walbourn Nov 11 '14 at 06:32