When compiling an engine to a DLL, would you use COM?
Author
Right now I am using COM, and I am just wondering if that was the best route to take. I'm kind of just curious as to if people use COM or just LoadLibrary and define their own interface.
Thanks :)
Depends what you want to do with it. If you're developing a pet project on your own, and you just want to use C++ I wouldn't bother. COM is great if you want to interoperate with most languages (where it is effectively the new C), or when you have lots of clients or developers who need a common standard.
Don't forget .NET is really COM with the ugliest bits hidden
Manually coding COM components in C++, at least from a beginners perspective is a nightmare. The wizards make it a bit more tolerable but it's still ugly - worse if you want to use IDispatch it looks like interface soup after a while.
There are some really good implementations available for using loadlibrary, the C/C++ Users Journal is a good place to start looking for snippets.
Don't forget .NET is really COM with the ugliest bits hidden
Manually coding COM components in C++, at least from a beginners perspective is a nightmare. The wizards make it a bit more tolerable but it's still ugly - worse if you want to use IDispatch it looks like interface soup after a while.
There are some really good implementations available for using loadlibrary, the C/C++ Users Journal is a good place to start looking for snippets.
Author
Cool thanks for the input.
I have zero problems coding in COM, I have used it for a long time.. just not in game development.
I just wanted to check and see if other people use COM in the engine DLL like I did. If not I was just wondering if any advantages were offered.. but really I can't think of any only downsides.
I have zero problems coding in COM, I have used it for a long time.. just not in game development.
I just wanted to check and see if other people use COM in the engine DLL like I did. If not I was just wondering if any advantages were offered.. but really I can't think of any only downsides.
Quote:Original post by XXX_Andrew_XXX
Don't forget .NET is really COM with the ugliest bits hidden
No it isn't. The .NET framework provides all the benefits of COM and more, that is true. But it it isn't *based* on COM, it is not a wrapper around COM and COM isn't used to implement it.
Quote:Original post by Integra
Right now I am using COM, and I am just wondering if that was the best route to take.
Well, what is the purpose? What goal are you trying to achieve by using COM components? If you can't answer this question, then you probably don't need to use COM.
Author
Quote:Original post by CoffeeMugQuote:Original post by Integra
Right now I am using COM, and I am just wondering if that was the best route to take.
Well, what is the purpose? What goal are you trying to achieve by using COM components? If you can't answer this question, then you probably don't need to use COM.
Well I had a couple of reasons in mind.. although maybe they are not the best? If these don't seem like good reasons than please let me know, I mean if using COM in this situtation is wrong I would like to know.
Two biggest reasons for using COM:
1.) Standard Interface, any COM programmer will be able to understand the interface quickly instead of trying to learn my own homegrown one (although it would probably not take much to learn).
2.) Backwards compatibility (probably the biggest here), because I am building a library that will be expanded on largely, but will always need to remain backwards compatible (ala DirectX).
Please let me know if these are not the best of reasons using COM, as I could easily swap out for my own loading/interfacing fairly easily... it's actually mostly written.
I don't see any downsides to using COM for an engine (performance-wise, as I know COM adds a little more complexity to building the engine but this is not an issue for me), are there any?
Surely if you're using your engine as a DLL (for some perverse reason), the last thing you want to do is further complicate things by using COM?
COM might not slow things down at runtime, but it will definitely increase complexity.
All apps should obviously be early-linked with the exact version of the DLL you will be using at runtime - that way you will have the least compatibility problems.
And if you're doing that you may as well make it a static library, as the result is approximately the same.
So I'd say - don't LoadLibrary, just link it.
Mark
COM might not slow things down at runtime, but it will definitely increase complexity.
All apps should obviously be early-linked with the exact version of the DLL you will be using at runtime - that way you will have the least compatibility problems.
And if you're doing that you may as well make it a static library, as the result is approximately the same.
So I'd say - don't LoadLibrary, just link it.
Mark
Quote:Original post by markr
Surely if you're using your engine as a DLL (for some perverse reason), the last thing you want to do is further complicate things by using COM?
COM might not slow things down at runtime, but it will definitely increase complexity.
All apps should obviously be early-linked with the exact version of the DLL you will be using at runtime - that way you will have the least compatibility problems.
And if you're doing that you may as well make it a static library, as the result is approximately the same.
So I'd say - don't LoadLibrary, just link it.
Mark
I disagree with this. Dynamic linked libraries and -objects offer the advantage of not having to recompile your project(s) once you've changed or modified the interface.
Image you not only added new functionality but also improved the existing interface implementations. Do you really want to recompile each project to benefit from that? Or build two different versions of the engine? I guess not.
Static linking is good if you have a solid library that won't change anymore. It's good for small class libraries but certainly not for large scale projects such as a complex game engine.
Dynamic linking has its place here.
Author
Quote:Original post by markr
Surely if you're using your engine as a DLL (for some perverse reason), the last thing you want to do is further complicate things by using COM?
COM might not slow things down at runtime, but it will definitely increase complexity.
All apps should obviously be early-linked with the exact version of the DLL you will be using at runtime - that way you will have the least compatibility problems.
And if you're doing that you may as well make it a static library, as the result is approximately the same.
So I'd say - don't LoadLibrary, just link it.
Mark
That is impossible for me to do, I have a patcher that updates the DLL which is why is accessing it dynamically. That way the engine is able to be updated without redistributing or reinstallation.
Also I know COM adds a tiny layer of complexity, but really I don't know why people really think it's that complex. Once you have your base set up the rest is pretty simple.
EDIT:
Quote:
All apps should obviously be early-linked with the exact version of the DLL you will be using at runtime - that way you will have the least compatibility problems.
Actually that is one of the main properties and uses of COM... being able to load the correct version you need even from a newer DLL, because COM is kept backwards compatible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
