To COM or not to COM?
Author
I posted this a little while ago and got some responses.. but I was hoping to get just a little more feedback on what people do.
If you were building an engine/library that compiles to a DLL, would you use COM or would you just use LoadLibrary? Maybe someone could enlighten me to any advantages/disadvantages I'm not sure of.
I mean with COM I would be presenting a standard interface that any COM programmer should be able to pick up, and even non-COM programmers shouldn't have a problem at all with it. Whereas with LoadLibrary I need to roll my own interfaces and the client needs to learn them.
One reason I was going to choose COM was because I wanted to make sure I could compile new versions and updates of the engine/library and distribute the DLL.. the end-user should be able to just upgrade to it seemlessly without breaking applications (incase it is used by multiple applications).
I know that obviously with COM I am not cross-platform, but this project is solely aimed at Windows 2000/XP/2003 users making use of DirectX for graphics.
So are there any actual drawbacks to using COM over LoadLibrary? I guess my main question is.. why would I not use COM?
Thanks for any input, it is much appreciated :)
Friends don't let friends use COM.
...or DOS.
...or DirectX.
...or IE.
I think NT is still okay to use. :)
...or DOS.
...or DirectX.
...or IE.
I think NT is still okay to use. :)
Author
Whoa ok I sense that people do not like COM :) Is there any particular reason?
Well if I were to roll my own interface instead of using COM, would I want to do it as shown here or is there an article or whitepaper on a better way?
I have implemented a COM version, and a version that works just like this article mentions. I just don't seem to like the way I have it implemented (how the article has it).. using an interface of all virtuals and virtual destructors.
Is that the best way?
EDIT: I should point out that I am runtime linking and not loadtime linking.
Well if I were to roll my own interface instead of using COM, would I want to do it as shown here or is there an article or whitepaper on a better way?
I have implemented a COM version, and a version that works just like this article mentions. I just don't seem to like the way I have it implemented (how the article has it).. using an interface of all virtuals and virtual destructors.
Is that the best way?
EDIT: I should point out that I am runtime linking and not loadtime linking.
I had a long post, but it was eaten by a 500 or something (I got a 500, but refreshing the page I saw my post on there, but now it isn't here so I dunno..?).
Put simply, COM(meant for language-independance afaik) wasn't made to the same requirements a game engine would need(speed, clean interface), so it isn't the best solution for the situation.
COM, in C or C++ at least, means writing a _TON_ of code or using a third party library that half takes over your application. Neither solution is any fun. Not only that, but in general the documentation for writing things yourself or using a library aren't so great. In a serious scour of the web, I found a _SINGLE_ book about writing COM manually (and even that only had a few chapters dedicated to that - the rest was MFC), and maybe two or three dedicated to com-only libraries (ie not counting MFC and whole-windows-wrapper libraries that take over ALL of your program).
Put simply, COM(meant for language-independance afaik) wasn't made to the same requirements a game engine would need(speed, clean interface), so it isn't the best solution for the situation.
COM, in C or C++ at least, means writing a _TON_ of code or using a third party library that half takes over your application. Neither solution is any fun. Not only that, but in general the documentation for writing things yourself or using a library aren't so great. In a serious scour of the web, I found a _SINGLE_ book about writing COM manually (and even that only had a few chapters dedicated to that - the rest was MFC), and maybe two or three dedicated to com-only libraries (ie not counting MFC and whole-windows-wrapper libraries that take over ALL of your program).
Author
I guess I'll try to find the best way to roll my own interfaces and not use COM then. Without COM I was using a struct of pure virtuals with a virtual destructor, so there has to be a better way than this right?
Quote:Original post by ExtrariusYou do know DirectX is COM-based? I wouldn't call DirectX slow or cluttered.
Put simply, COM(meant for language-independance afaik) wasn't made to the same requirements a game engine would need(speed, clean interface), so it isn't the best solution for the situation.
On a related note: Mozilla (and therefor Firefox) are based on COM too (XPCOM). So comparing COM to Hitler is a bit lame...
DX is still based on COM and I don't think that's gonna change. Unless of course they stop updating the unmanaged verison of DX and only update the managed (.Net) version. But then .Net is sort of the evolution of COM.
Well you have pretty much the same thing with COM. Personally I'd have no problem with using COM within a game engine. Whats the point of recreating something that's already there?
Quote: Without COM I was using a struct of pure virtuals with a virtual destructor
Well you have pretty much the same thing with COM. Personally I'd have no problem with using COM within a game engine. Whats the point of recreating something that's already there?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement