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
Why DX use pointers for everything?
Hi, i''m just wondering why directx uses so many pointers. Is there a design reason behind this?
eg
...
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.
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.
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]
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]
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,
Ken
Drunken 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.
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
Static
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement