Exceptions, COM, and DirectX pointers

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Exceptions, COM, and DirectX pointers

      Hello all,

      I'm working on my first game project and am trying to wrap my head around how best to use exceptions and error codes. In particular, what gets me is not being entirely sure about how to handle construction of objects that make DirectX calls.

      On Mike's book, p. 206 "Exception Handling" addresses this issue by throwing a custom error exception. I've seen other texts such as "C++ for Game Programmers" by Noel Llopis refer to the idea of using smart pointers to hold all pointers so memory leaks are avoided.

      For example, if I'm creating a renderable object, it will probably hold a pointer to a DirectX texture (LPDIRECT3DTEXTURE8). If this is initialized during construction, but some other later step fails and an exception is thrown, aren't I at risk of leaking this memory for the texture? (assuming my class holds a private member variable LPDIRECT3DTEXTURE8)

      Thanks for the great book Mike, and thanks all for your advice!


      The post was edited 1 time, last by etldan ().

    • RE: Exceptions, COM, and DirectX pointers

      As long as your class goes out of scope with the exception, and your class effectively releases the DirectX texture, you shouldn't leak memory.

      One way to make sure you don't leak is to wrap your classes that manage DirectX objects in a smart pointer - which is better than reference counting because exceptions won't know to call a Release(), necessarilly.

      It might help if you post a code snippet - and let us take a closer look at your solution.
      Author, Programmer, Brewer, Patriot
    • Here is what I have right now, and am working on implementing a clean error handling system. (to deal with the cringeworthy ignoring of the HRESULTs!)

      Source Code

      1. TriangleSprite::TriangleSprite( .. size params, etc. )
      2. {
      3. HRESULT tempHR = initVertexData();
      4. m_pTexture = NULL;
      5. tempHR = initTextureData();
      6. // and then init some more physics and other stuff
      7. }
      8. TriangleSprite::~TriangleSprite()
      9. {
      10. if ( NULL != m_pTexture )
      11. m_pTexture->Release();
      12. if ( NULL != m_pVertexBuffer )
      13. m_pVertexBuffer->Release();
      14. }
      15. HRESULT TriangleSprite::initVertexData()
      16. {
      17. // init our LPDIRECT3DVERTEXBUFFER8
      18. }
      19. HRESULT TriangleSprite::initTextureData()
      20. {
      21. // init our LPDIRECT3DTEXTURE8
      22. }
      23. HRESULT TriangleSprite::frameUpdate()
      24. {
      25. // do our per-frame updates such as motion, etc.
      26. }
      27. HRESULT TriangleSprite::renderFrame()
      28. {
      29. // Render our sprite to the D3D screen
      30. }
      Display All

      Right now I'm holding my list of renderable game objects (such as this TriangleSprite) in a vector of boost::shared_ptr's for exactly the reason you mentioned. I chose the boost shared_ptr because I read that STL's auto_ptr doesn't fit nicely in an STL container.

      So my constructor could catch those HRESULT error codes and throw an exception if any of them failed? (And my exception class could map the HRESULT to a string, file, and line, or something meaningful like that)

      Then, if an exception is thrown in the constructor, say after the Texture is created and initialized, how do I deal with releasing this memory?

      Thanks much!

      PS. Right now all my game objects are directly aware of DirectX which I know is a bad thing since it directly ties the game to DirectX, the class imports all the D3D headers, and the code has ugly inside knowledge/access to D3D data structures, etc etc. I haven't separated these yet but would appreciate any suggestions for articles, etc. that give pointers how to do this effectively.