我在創建一個簡單的2D遊戲引擎的同時，更深入地從C++開始。在我的引擎我有（或希望有）的「抽象」 GameEntity類，它攜帶的方法draw，update，也許position（X，Y）。在我看來，我會添加更多的東西。使渲染方法虛擬？
類從GameEntity繼承將是任何可能在屏幕上繪製（ParticleSystem，MovingSprite，StaticSprite，GuiMenu，等...）
我的問題是，要實現這一點，我已經宣佈GameEntitydraw()和update()方法虛：
virtual draw()=0;
virtual update()=0;
所以ParticleSystem都有它自己的平局和MovingSprite也有它自己的draw()（和update()）。
我知道虛函數是昂貴的，或者至少比普通方法更昂貴。你認爲我所做的事很糟糕嗎？或者太糟糕了？如果你這樣做，我會非常感激一個更好的方式來做到這一點。
謝謝！
不，這不壞;開銷不是那顯着（你可以諮詢this answer to another question）。
例如，這是基於OpenGL的開源場景圖OpenSceneGraph採取的一般方法。 OSG具有a Node class，從中派生出場景圖中使用的所有節點類型，並使用大量的虛擬功能。
感謝您的回答，我碰巧也爲我的遊戲使用了SceneGraph，但它更簡單一些，我現在只允許在場景中使用子節點列表（不需要支持子節點的樹結構但）。 – Goles 2009-11-18 11:28:44
如果你真的需要在運行時處理多個案件（我認爲你這樣做，在這種情況下），最好是使用虛擬功能。編譯器可能會優化它，或者甚至比if-else聲明更好，因爲虛擬函數類似於if-else的特例。
我上現在的工作系統使用虛擬平局（）和update（）在3D層樹;我們的性能瓶頸不在虛擬調度中。我認爲你的設計可以從一開始;如果你認爲這真的很糟糕，你可以稍後再分析。它是什麼，一個負載和一個跳躍？
調用一個虛函數的成本通常比兩次指針間接尋址更多的是正常的函數調用，所以這是一個非常小的開銷，應該幾乎從不重要。
另外，包含函數的對象的大小大於沒有任何虛函數的對象（它們包含指向對象虛函數表的指針）的大小。但是，如果你不打算有太多的小物件，這也應該不重要。
詳情請參閱C++ FAQ lite。
並回答你的問題：我認爲它應該可以正常工作。
你有沒有注意到你的代碼變慢了？我對此表示懷疑。良好的設計>微型優化。 – GManNickG 2009-11-18 05:08:45
感謝所有的答案，我想我一點也不會這麼做！ – Goles 2009-11-18 11:29:15