Hi guys. Yes, it's a really newbie question hehe.
But I'd like to know if theres some way to pass (for example) a ID3D10ShaderResourceView * variable as a parameter to another function and make sure that particular function is not gonna change it in any way.
I have a class who has a ID3D10ShaderResourceView * variable holding depth values to perform shadow calculations, a shadow map so to speak. And another class who makes the actual rendering, so I'd need to pass this shadow map to the rendering class but in doing so I guess I'd be violating the encapsulation principle since the rendering class could do whatever he likes with my shadow map.
Do I have design issues, could I do this in another way or is there some way to fix it or am I getting worried for too little?
Regards
Passing a const COM interface as parameter
Hi!
That depends on how much work you’d like to have.
In the end your rendering code needs a non-const version of your SRV, since PSSetShaderResourceView() etc don’t accept const objects.
For this reason I prefer making my Dx objects not const (if I make them accessible by getters).
A class holding the SRV could airily define a getter like this:
Someone calling this can’t mess with your _SRV pointer. (It can’t be set to NULL for instance.)
You can’t dereference it, since it is abstract. It doesn’t have any public members…
And it is a view after all, right? So you can’t do much with that except looking at data.
(Except changing its debug name, releasing some refs or getting the resource beneath, define render target views on it and clear it a little… Well, but who does that? If you’d try making it const-correct you could as well cast the const away…)
If you really want to limit the doable damage, then don’t expose it at all. Wrap the ID3D11ShaderResourceView in an own class and give it methods like:
Then you can make this as const-correct as you want.
In most cases (since I mainly make small tech demos) I prefer the first approach (Dx objects not const at all).
However, I’d be interested in the ways other people handle that!
That depends on how much work you’d like to have.
In the end your rendering code needs a non-const version of your SRV, since PSSetShaderResourceView() etc don’t accept const objects.
For this reason I prefer making my Dx objects not const (if I make them accessible by getters).
A class holding the SRV could airily define a getter like this:
ID3D10ShaderResourceView* GetSRV() const { return _SRV; }
Someone calling this can’t mess with your _SRV pointer. (It can’t be set to NULL for instance.)
You can’t dereference it, since it is abstract. It doesn’t have any public members…
And it is a view after all, right? So you can’t do much with that except looking at data.
(Except changing its debug name, releasing some refs or getting the resource beneath, define render target views on it and clear it a little… Well, but who does that? If you’d try making it const-correct you could as well cast the const away…)
If you really want to limit the doable damage, then don’t expose it at all. Wrap the ID3D11ShaderResourceView in an own class and give it methods like:
static void BindPS(ID3D10Device* device, UINT StartSlot, UINT NumViews, const MySRV* const* Srvs )
{
ID3D10ShaderResourceView* srvs[D3D10_COMMONSHADER_INPUT_RESOURCE_SLOT_COUNT];
for (int i=0; i<NumViews; ++i)
srvs = Srvs->_srv;
device->PSSetShaderResources(StartSlot, NumViews, srvs );
}
Then you can make this as const-correct as you want.
In most cases (since I mainly make small tech demos) I prefer the first approach (Dx objects not const at all).
However, I’d be interested in the ways other people handle that!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement