Quote Originally Posted by tescrin View Post
As someone who's been digging into COM for a few weeks, while it is one possible solution (as it'll be a layer between the two) it's... a lot of work.

Further, it won't necessarily be compatible if you shift it somewhere else. In order to use COM you'll have to be adding (at least one) entry to the registry and accessing it at runtime. Unless you build a proper install/batchfile/something this won't be usable by another computer without manually editing the registry (or using your batch file that does it for you manually.)

That said, COM will work, but it's the long road to success here. I imagine the tuts that high_flyer mentioned will be easier.



COM Stuff:
If you wish to do COM I'll suggest the book i've been going through: COM and ATL 3.0 by Andrew Troelson. It gives a good quick-and-dirty hands on of COM by first pretending to build COM like client/servers with C++, then moving into building actual COM objects by hand, then using ATL to actually use COM more efficiently. Most material you find on standard COM *WILL* be 8 years old or so. COM doesn't change over time! (An extremely important concept.) To expand COM they add new classes (either inheriting from old ones as a means to "update" them, or building entirely new classes.); I.E. COM+ adds a bunch of features by subclassing or adding new content. Standard COM usage hasn't and (AFAIK) won't change; so old material is gold aside from deprecated C++ headers and such. The book I mentioned happens to be at least 10 years old and I've had no issues compiling or getting the code to run just fine.

Still, seems like a very complicated way to utilize a DLL between languages for something this small. COM is more for an official release that you want:
--People to be truly abstracted from the implementation
--People to be able to use several language types in a compatible way (i.e. a company building a large project with many different programmers specialized in different languages)

A good example is a project I'm working on where I'm tearing a GUI away from it's COM layer and replacing it. By using COM I don't have to actually change anything but GUI code to update it. This is good because the language it's currently in is now unsupported so being able to recode only this portion of it leaves a usable product.

Similarly as long as you conform to the contract COM allows you to update from the other direction. You could replace the entire codebase that controls your hardware beneath the GUI implementation, without ever touching the COM layer or the GUI layer.
Thanks for the information. The actual project which I'm going to be using is actual much larger, the small class above was just an example I'm working with so I'll get started.

I've tried to use the unmangled dll import and it seems to work, so long that I don't use any QT code. I'm gonna keep on that track I think because as you said, the COM way seems like it's alot of extra work, would be nice though. Thanks everyone!