• 13
• 18
• 19
• 27
• 10

maintain the object or pass it in every call

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

Recommended Posts

Which woould be better?
// #1
class IRenderable
{
public:
IRenderable(){}
~IRenderable(){}
Render(LPDIRECT3DDEIVCE9 pD3dD) = 0;
}
//
//#2
class IRenderable
{
public:
LPDIRECT3DDEVICE9  m_pD3dDevice;
IRenderable(LPDIRECT3DDEIVCE9 pD3dD){m_pD3dDevice = pD3dD;}
~IRenderable(){m_pD3dDevice = NULL}
Render() = 0;
}


I know that both of these are workable solutions.. most code samples i see #1 seems to be used, but wouldn't keeping a class variable be more speed effecient or maybe the variable should be static?

Share on other sites
In my view, it depends on a couple of things. First, will it be used very often? If so, I generally have it as a class member. Second, is it subject to change often, or suddenly. If so, leave it as something to be passed in.

Share on other sites
thats my take on it as well..
is there any penalty for accessing static members.. is it slower than a non static member?

Share on other sites
Quote:
 Original post by MTclipthats my take on it as well..is there any penalty for accessing static members.. is it slower than a non static member?

Why are you making it static in the first place? That seems like a rather pointless limitation.

CM

Share on other sites
oh i am not going to make it static.. the question of static was meant to just be a general question... also how would that be a limitation?

Share on other sites
Quote:
 Original post by MTclipoh i am not going to make it static.. the question of static was meant to just be a general question... also how would that be a limitation?

In general, the biggest performance issue is how it affects your cache. Static members aren't stored with the other members, so when you access it you're much more likely to have a cache miss. And those are expensive.

The reason its a limitation is that it forces all your renderable objects to use a single D3D device. While I'm usually not one to promote complicating designs in the interest of illusionary "what if" scenarios, in this case you aren't really complicating anything. Just provide the device in your constructor, and you're good to go. All it costs you is a single pointer, a cost which is probably dwarfed by the objects textures and whatnot anyhow.

CM

Share on other sites
cache hits and misses is one area i dont really know anything about...

anyone know a place to read up on that

Share on other sites
Quote:
 Original post by EndarIn my view, it depends on a couple of things. First, will it be used very often? If so, I generally have it as a class member. Second, is it subject to change often, or suddenly. If so, leave it as something to be passed in.
My thoughts exactly.
Here's a few more things to consider:
If you pass it in every time, and you internally call another function, which calls yet another internal function etc, then you can end up with parameter bloat.

If you have a lot of these and you store a LPDIRECT3DDEVICE9 in each one, then you'll use more memory. You'll also make it harder to change the LPDIRECT3DDEVICE9 pointer later, and there'll be many objects to update.

A third approach would be having all of your IRendable's access the LPDIRECT3DDEVICE9 from a common place, such as a singleton? It has the advantages of minimal memory usage and minimal parameter passing. Of course it is by far the least flexible.

You choose![smile]