Why DX use pointers for everything?

Started by
16 comments, last by johnnyBravo 19 years, 11 months ago
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
Advertisement
Because that''s how COM interfaces work.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

...

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.
I''m pretty sure most of that is wrong, transformation.
-Unsuspected
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]

Niko Suni

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
Stay Casual,KenDrunken Hyena
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.
Plus, it wouldn''t be C comptatible. C++ really needs to let go of C now.
And the rockets' red glare, the bombs bursting in air,gave proof through the fight that our flag was still there.Oh say, does that star-spangled banner yet waveover the land of the free and the home of the brave?
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
"->" > "."

This topic is closed to new replies.

Advertisement