Sind lange Initialisierungslisten böse?

Hier ein Beispiel:

DeferredRendering::DeferredRendering(ID3D10Device* pd3dDevice, ID3D10Effect *pEffect, ID3D10Effect *pCubeMapEffect) : 
m_pPickBuffer(0),
m_pVertexLayoutScreenQuad(0),
m_pVertexLayoutHUD(0),
m_pHUDTechnique(0),
m_pVertexBufferFullScreenQuad(0),
m_pTexture(0),
m_pNoiseTexture(0),
m_pRandom(0),
m_pCullCWRS(0),
m_pDrawMirrorDSS(0),
m_pDrawReflectionDSS(0),
m_pDrawReflectionBS(0),
m_pDepthStencilTexture(0),
m_pDepthStencilView(0),
m_pEffect(0),
m_pShadowMapEffect(0),
m_pGeometryPassTechnique(0),
m_pLightPassTechnique(0),
m_pLightPassKugelTechnique(0),
m_pTexRender10(0),
m_pTexRenderRV10(0),
m_pTexRenderRTV10(0),
m_pTexBrightPass10(0),
m_pTexBrightPassRV10(0),
m_pTexBrightPassRTV10(0),
m_pMSRT10(0),				
m_pMSRTV10(0),
g_pDSV(0),
g_pDepthStencil(0),
m_pMSDS10(0),
m_pMSDSV10(0),
m_pTransparentObjectMapSRV(0),
m_pTransparentObjectTexture(0),
m_pTransparentObjectMapRTV(0),
m_pEnableAdditiveBlendingBS(0),
m_pDisableDepthTestSS(0),
m_pTransparentPass(0),
m_pTransparentTex(0),
m_pGhostFigureColor(0),
m_pGhostMode(0),
m_vSourceDimensions(0),
m_ptxShadowMap(0),
g_pmViewCM(0),
m_pAmbientOcclusionSRV(0),
m_pAmbientOcclusionRTV(0),
m_pAmbientOcclusionTexture(0),
m_pSSAOTechnique(0),
m_pBlurXTechnique(0),
m_pBlurYTechnique(0),
m_pBlurXSRV(0),
m_pBlurXRTV(0),
m_pBlurXTexture(0), 
m_pBlurYSRV(0),
m_pBlurYRTV(0),
m_pBlurYTexture(0)
{
	// set g-buffer to 0
	for (int i = 0; i < NUM_GBUFFER_TEXTURES; i++)
	{
		m_pMapVariable[i]=0;
		m_pRenderTargetView[i] = 0;
		m_pRenderTargetTexture[i] = 0;
		m_pRenderTargetShaderResView[i] = 0;
	}

Sollte man lange Initialisierungslisten vermeiden und diese n den Konstruktor verlagern?

Nexus

MuhkuhReloaded schrieb:

Sollte man lange Initialisierungslisten vermeiden

Wenn sie derart ausarten wie in deinem Beispiel, ja.

MuhkuhReloaded schrieb:

und diese n den Konstruktor verlagern?

Nein nein nein! Das löst doch das Problem hinten und vorne nicht. Das Problem ist nämlich, dass du zu viele Membervariablen hast. Das schreit doch nach Objektorientierung. Fasse zusammengehörige Attribute zu eigenen Klassen zusammen, dann verkürzt sich automatisch die Initialisierungsliste.

drakon

Per se böse nicht, nein.

Was du dich hier eher fragen solltest, ob die Klasse so gross sein muss oder du das das ganze nicht besser aufteilen solltest.

Du hast da ja einige Effekte implementiert, so, wie ich das sehe und die könntest du doch sehr schön auslagern. Dann kannst du nämlich z.B den Blur benutzen ohne auch gleich das ganze Zeugs für AmbientOcclusion mitschleppen. Da würde sich das ganze dann schon sehr verkleinern.

das ist so, als ob Du fragst, ob das Tachometer des Autos böse ist, wenn es in geschlossenen Ortschaften über 100km/h anzeigt.

Wie drakon und Nexus bereits geantwortet haben ist nicht die lange Initialisierungsliste böse, sondern die Größe Deiner Klasse - sowas nennt man ein Gott Objekt.

asc

Ich erinnere mich das im Buch "Code Complete" eine Empfehlung für 3-7 Membervariablen pro Klasse gemacht wird. Das hört sich für viele als sehr wenig an, da die Membervariablen aber durchaus auch wieder Klassen sein können, ist diese Richtlinie nicht unbedingt so abwegig (Auch wenn ich mich nicht komplett auf die 3-7 festbeißen würde).

Walli

3-7 kommt bei mir gut hin. Ich fange aber nicht unnötig an zu kapseln, wenn es mal 10 werden sollten.