Archived

This topic is now archived and is closed to further replies.

johnnyBravo

Why DX use pointers for everything?

Recommended Posts

Hi, i''m just wondering why directx uses so many pointers. Is there a design reason behind this? eg
quote:
if(FAILED(diDevice->CreateDevice(GUID_SysMouse, &lp_Mouse, NULL))) return E_FAIL; if(FAILED(lp_Mouse->SetDataFormat(&c_dfDIMouse))) return E_FAIL;
Like why not just use non pointers for example(bad example): diDevice.CreateDevice... instead of diDevice->Create..... Anyway you know what I mean

Share this post


Link to post
Share on other sites
...

Someone else correct me if I''m wrong please.

DLLs have their own memory space. And to create a class using C++ with a dll, the only way is to create it inside a DLLs memory space a pass it back to an application. If you pass the whole object, you''d have to pass the object through DLL memroy boundrys which cause problems. Also another thing is that even if passing memory though boundries didnt cause problems, you''d be releasing the memory inside your application. And if you create an object in a DLL and have destruc inside an application, you''d get problems. You can try it yourself

Create a DLL of some class and export a function that returns a pointer to that class.

Now in main do

{
MyClass* p = DLLFunctionGetClass();
delete p;
}

DLLFunctionGetClass would just bre turning a new instance of the class.

Another reason is that you cant have a DLL produce objects on the stack. So a pointer to the object is the only way to go.

I know somethings I''ve said are right and some are wrong... Hopefully someone will pick the wrong things out. But the above is my reasoning behind your question.

Share this post


Link to post
Share on other sites
The real main reason for this behavior is, that the COM classes can return result codes (AKA HRESULT codes) to let the client know whether the operations were succesful or not.
The client can therefore act accordingly, and is free to decide if it should go on, try something else, or just quit if the class in question is vital in succesfully executing the client.

-Nik

EDIT: And usually the HRESULT codes even tell the client what exactly went wrong, in case of error. DX is a good example of this particular trait, IMO.

[edited by - Nik02 on April 21, 2004 5:28:52 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Nik02
The real main reason for this behavior is, that the COM classes can return result codes (AKA HRESULT codes) to let the client know whether the operations were succesful or not.
The client can therefore act accordingly, and is free to decide if it should go on, try something else, or just quit if the class in question is vital in succesfully executing the client.

-Nik

EDIT: And usually the HRESULT codes even tell the client what exactly went wrong, in case of error. DX is a good example of this particular trait, IMO.

[edited by - Nik02 on April 21, 2004 5:28:52 PM]

wtf does this have to do with pointers?!

I''m pretty sure its because the device is not a concrete class, your video drivers create a class ''derived'' (its a bit different in COM from what i understand) from IDirect3DDevice*. when you call CreateDevice, its probably asking the video driver to instantiate a class derived from IDirect3DDevice8, and the driver gives you one back that interfaces directly with it. if you used:

IDirect3DDevice8 d3dDevice;
d3dDevice.blah();

the object would need to be known at compile time. this is also probably how directx does things like the reference rasterizer, it is just a concrete class created from IDirect3DDevice8, like CDirect3DReferenceDevice8 or some such.

i would think opengl does something simliar, except the video drivers export functions from a DLL for you to use instead of deriving from a class.

Share this post


Link to post
Share on other sites
When passing a variable by value you make a copy of it. So if diDevice was not a pointer do_something(diDevice) would make a copy of diDevice. You would not be modifying or interfacing with diDevice, but a copy of it.

Static

Share this post


Link to post
Share on other sites
quote:
Original post by PlayGGY
Plus, it wouldn''t be C comptatible. C++ really needs to let go of C now.


i think thats to just to make directx multi language, eg visual basic

Share this post


Link to post
Share on other sites
Probably cause DX thinks you are stupid and doesn''t want you making a million instances of its devices like I know so many would. So it just defined a large sets of pointers to use.

Also a couple of you guys posts are entirely wrong:
"i think thats to just to make directx multi language" - wrong
"DLLs have their own memory space..." - entirely off subject and reading it made me forget at least 2 years of programming experience

Also here is a good start to learning what pointers even do and why you need them...

http://www.cplusplus.com/doc/tutorial/tut3-3.html

Share this post


Link to post
Share on other sites
billybob's answer is closest to the truth. I'll explain this a little more, though please note that what I'm going to say isn't the exact state of things. That's because COM - which is what this is all about - is a huge topic. I'd recommend you read MSDN to find out exactly what's going on with it - it's good stuff to know about in any case.

IDirect3D9 is not a real class. You can't create objects of it, because no such objects exist. It's a pure abstract class - one made up entirely of pure virtual functions, which are basically function prototypes that child classes are forced to implement.

DirectX, interally, has at least one class which is derived from this IDirect3D9 class, implementing all of its functions. You are never allowed to know the name of this class, or to work with it directly; it is created for you by Direct3DCreate() (which just calls CoCreate() internally), and you get back the interface through which you are allowed to use it.

Theoretically, the object you're actually dealing with could also be the same object which handles XML parsing and triangular button controls. However, it might not be. So in order to prevent anyone from making any assumptions about what the object can actually do, you're not told anything about the object outside of the interface you've been given.

So, rather than just hand you the entire object - let you create it with new Direct3D9() and the like, which requires that you know all the details of the class definition, including other things that the class does - it keeps the object, and gives you a pointer to the part of the object you're interested in - the Direct3D functions, which are all conveniently wrapped up in a single 'interface' class, IDirect3D9.

That's about it. To deal with a couple of the other issues raised in this thread:

Nik02: That's all true, but HRESULT return values could be achieved just as easily with a 'true object' approach.

DrunkenHyena: LOL

PlayGGY: It would, in theory, be possible to handle C++ objects in C. You'd end up with code like this:

Direct3DDevice_Present(&myDirect3DDeviceStructure, NULL, NULL, NULL, NULL);

Basic class features in C++ - member functions at the very least - can be approximated in C.

glassJAw: Ah, but in Soviet DirectX, "." > YOU

jimmynelson: there is a certain amount of object reuse going on, but it's not that DirectX wants to prevent you from creating a whole load of objects. You can still do that anyway, just call Direct3DCreate9 a second time.

[edited by - Superpig on April 22, 2004 4:04:30 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by DrunkenHyena
The REAL reason is that many of us are paid by the character, so when we write device.CreateDevice we get less money than if we write device->CreateDevice.


Stay Casual,

Ken
Drunken Hyena


Why don''t we start adding spaces and tabs everywhere? To make our code ''look better''?

--
You''re Welcome,
Rick Wong
- Google | Google for GameDev.net | GameDev.net''s DirectX FAQ. (not as cool as the Graphics and Theory FAQ)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Pipo DeClown
Why don''t we start adding spaces and tabs everywhere? To make our code ''look better''?



Because that would slow the code down. I want my game to have the highest frame rate possible. Even though spaces (and comments) make the code much easier to read, they totally kill the frame rate.

Share this post


Link to post
Share on other sites
meh this post some how got reopened a month later,
no wonder i vaguely remember posting this stuff

anyway ..................im too tired to continue

Share this post


Link to post
Share on other sites