   Why most DirectX objects are stored as pointers
  Hi all,I am reading up on Direct3D and is wondering why majority of the objects, such as IDirect3DDevice9 or IDirect3DStateBlock9 are stored as pointers?Perhaps on a slightly related note, when do you choose to instantated an object with new, and when do you create it on the stack?   
  Direct3D uses a component framework, and the pointers are references to a table of methods that reference an implementation for the component.  In short, Direct3D uses Microsoft's Component Object Model, or COM.  There are other frameworks like COM, such as XPCOM which is used in Mozilla-based products like Firefox, and CORBA.Most enterprise-class software frameworks use similar abstractions.;  Let me answer the second question first.  Whenever you create an object with new, it's put on the heap.  The heap has basically unlimited space (up to about 2GB under Windows), but does have a performance cost.  This performance cost is greatest at memory allocation and deallocation (new and delete).  It is therefore advisable to use heap memory for large objects, or large arrays of small objects, that are not created and deleted very often.Additionally, if an object needs to survive past the end of the function in which it was created, it needs to be created with new and the pointer stored for later use.A very bad way to use new:int main(){  for(int i = 0; i < 100000; i++)  {    SomeClass *c = new SomeClass(i);  //Slow.    c->Process();    delete c; //Very slow.  }  return(0);}The reason that DirectX objects are typically delivered to you as pointers is that they need to survive the entire execution of your program (until you manually release them, anyway), and that they're large enough that even if you only needed such objects locally, they would take up a significant portion of your stack space.More technically, the reason that heap allocations are so much slower is that objects are allocated and deallocated at arbitrary locations in the heap.  Whenever you call new, the system searches the heap for an available slot of at least the size that you requested.  This can take some time.  When deleting an object, the system has to update its internal data about the stack, combining neighboring available memory chunks into larger ones, etc.  Memory tends to become fragmented over time (just like a hard drive after numerous file creations and deletions), which hurts performance.Stack allocations, on the other hand, are absolutely free.  The stack is, basically, one big chunk of the heap that's reserved for bookkeeping and local variables.  When you call a function, information about that function (including parameters, the return address in memory where the program should go back to when returning from the function, etc.) is added to the top of the stack.  Because it is known that no other objects will be inhabiting the memory above the top of the stack, none of the mess I described above for the heap applies.  The system just increments its internal "top of the stack" pointer by the appropriate amount and immediately begins treating that memory block as described by the function.  So adding ten 4-byte ints as locals to a function does nothing to decrease performance.  It just eats up 40 more bytes of stack memory.This also explains why uninitialized variables are such a hazard in C++.  When that function is called, those local variables take on the value of whatever happened to be stored at that location in stack memory.Note: As mentioned above, a more complicated construct is in use by DirectX, COM.  COM objects are, for the purposes of this discussion, suped-up pointers.  One such object can be used across different heap boundaries, blah blah blah.  It's a whole nother discussion.Well, that was a bit overkill for your question, but hopefully it clears some things up for you.  Feel free to ask more questions.   ;  You've got a couple of excellent answers already... but might I be the boring one and suggest you take a step back from DX if you're not completely comfortable with its architecture/pointers?I appreciate everyone wants to get straight on with the cool/fun stuff, but jumpin in at the deep end without knowing how to swim is a little risky [smile]Basic memory management is important with DirectX - using COM's reference counting model is one substantial part that you can't really afford to get wrong or you'll end up in memory leak hell. This is essentially an extension to the regular C/C++ pointer architecture.DirectX (via the COM) model does most of its work via interfaces and factory methods (e.g. D3DXCreate**() calls) - for this to work its essential to be passing around pointers and pointers-to-pointers (e.g. you'll see lots of functions taking IDirect3DTexture**).Best of luck getting things sorted - as suggested, do feel free to ask further questions. Although the 'For Beginners' and/or 'General Programming' are more suited to non DX API questions.Cheers,Jack   ;Quote:Original post by jollyjeffersYou've got a couple of excellent answers already... but might I be the boring one and suggest you take a step back from DX if you're not completely comfortable with its architecture/pointers?...snipped...Cheers,JackThanks for the caution. Basically, what happened is that I learnt C++ as my first language, but everything I did at University now is all Java, so I got a bit mixed-up. I am considering changing to MDX just because of all the issues I have with pointers.Nonetheless, thanks!   ;Quote:everything I did at University now is all Java, so I got a bit mixed-up. I am considering changing to MDX just because of all the issues I have with pointers.If you don't particularly want to learn C++, I can vouch for that choice. It's the same route I took and I have yet to regret it... Well, not counting the times the lack of documentation and samples for MDX got me stumped [wink] Even if you want to learn C++, MDX still is a good choice to learn how the API works first, especially when you're coming from Java. You'll have to get aquainted with managing video memory and resources, create an application that performs well in realtime and figure out how to get DirectX to actually display some halfway decent graphics. Not having to worry about complex new language concepts is a blessing there, I'd say [smile][Edited by - remigius on May 29, 2006 2:36:44 AM]