I'm working on a fairly large project written primarily in C++ using MFC. We are tasked to gradually port this application to use Qt. Years ago, a wrapper around much of our functionality was written using COM. I feel using the COM wrapper from the new Qt code will help isolate code that would force dependencies on MFC. Unfortunately, we're also being asked to ween our use of COM/ActiveX. So, introducing new consumers of our COM wrapper in Qt isn't ideal. Visual Studio has a class wizard that will generate a C++ class based on an interface in a TLB file, but it's dependent on MFC and the interface still exposes COM (LPDISPATCH, SAFEARRAY*, etc).
With all that said, does anyone know of a tool (free or commercial) that will take a Microsoft IDL file and convert it to C++, who's interfaces aren't dependent on MFC nor COM?
and working with the code generated by midl.exe
That's hang-up number one. Midl.exe does not generate code, it only generates declarations. Pure virtual classes in C++, only method declarations with no implementations. Either to a .h file or to a .tlb type library file. The type library is handy because it is easy to read by tooling, having a restricted sub-set of COM called Automation. And implemented by just about any language runtime on Windows.
Key point is that these are just declarations, the glue that makes code written in different modules and/or different languages or class libraries work together. Very important in large projects, interfaces tie the pieces together.
Our system architect learned of our approach and advised that we find a way to not add these COM-specifics to our new Qt projects.
That's singularly unhelpful advice. "Don't do that" is something my doctor tells me when it hurts to put my arm behind my back. I can live with that, I have a good alternative and can just turn around. In your case I would have to demand more from the architect. He's messing with the body parts, he's separating the torso from the legs and head and feet and hands. Brain utterly disjointed. The very glue that makes the different chunks of code you have now work together. Break that interface and you'll seriously break your app, Netscape style.
Beware of the astronaut architect (another Spolsky favorite) that's happy to force you into something that he understands but doesn't have to implement. Demand a reasonable alternative, an architectural approach since breaking the interfaces has a deep architectural impact on your app. Those MFC classes that everybody implemented from the interfaces are pretty much junk when you change the interface. Rewriting them all into Q classes is going to seriously keep you unproductive for a while. And is devastatingly boring code to write. Only to produce the same thing, with more bugs. Things You Should Never Do, part 2.
If you are able to keep using Visual C++, a solution would be to use the plain compiler support for COM.
You need to #import your TLB file
http://msdn.microsoft.com/en-us/library/8etzzkb6%28v=vs.100%29.aspx
Then you can make use of the COM compiler support to handle the COM object instances,
http://msdn.microsoft.com/en-us/library/h31ekh7e.aspx
Related
Can I use the WRL library in C++ as a replacement for ATL to write a COM component? And if yes, would I be able to use it on older desktop Windows systems, like Windows XP?
I'm pretty sure that the answer to the first question is positive as I found this tutorial on MSDN:
http://msdn.microsoft.com/en-us/library/jj822931.aspx
but what about non-Windows 8 systems?
Well, sure you can. You can write a COM server in pure C++ code without any helper classes at all. You can write one in C if you really want to, although that's a violation of the Geneva Convention on Programmer's Rights in most jurisdictions.
What is probably not so visible is what is missing. WRL just doesn't make it any easier to write a server. Or maintain it. What you'll miss out on:
No help whatsoever to implement IDispatch. Obsoleted in WinRT but still quite important in regular servers. The only way to consume the server from a scripting language, IDispatch provides the late binding support.
No help whatsoever for registration. Obsoleted in WinRT, required for regular servers. Note how the DllRegisterServer() entrypoint is missing. The page you linked patches around the problem by requiring you to write a registry script by hand. That works, it is not exactly something you'd want to maintain or document so IT staff can get it right.
No wrappers for Automation types like BSTR, VARIANT and SAFEARRAY. Obsoleted in WinRT along with IDispatch. You can still fall back to <comutil.h> however.
No help whatsoever from the wizards that are built into Visual Studio that help you get it right. COM servers are awkward because definitions appear in multiple places in your code. And need to be an exact match. You get no help to ensure that CalculatorComponent is an exact match with the IDL, it is entirely up to you. Compiler errors you get from making small mistakes, particularly when maintaining it, can be painful.
And a whole bunch if smaller stuff not worth mentioning, like apartments, ActiveX, aggregation, error info, etc. Hurts pretty bad when you need it though. A possible advantage of WRL is that there's less mystical glue, ATL has a fair amount of it that considerably raises the abstraction level. That was intentional but it has to be learned. There's none at all when you use pure C++ of course, albeit that you have to write too much of it yourself.
Yes. You can write a standard COM component.
There is a sample for this directly in the docs.
And no: Such a COM component will only run on Windows 8 and later...
I've got a DSP audio aglo in C# that I'd like to incorporate into iOS. A friend suggested that I convert to C++ instead of Objective-C, as it would be platform agnostic. Is this a good practice, any pitfalls to be aware of? My instinct is to keep it native with Obj-C. How would I access C++ functions within iOS?
Thank you
You can freely mix C++ with Objective-C, it's known as "Objective-C++". To let the compiler know that is your intent, you need to rename you .m file as .mm.
Mixing code like that is not necessarily a good idea, and fairly pointless if you aim is portability. Better is to keep you C++ in separate .cpp files, and create a bare-bones wrapper class (obj-c++) to pass data between your objective-C and C++ objects (effectively the wrapper is mediating obj-C methods and C++ functions to send and return data).
I have recently posted a couple of simple image processing examples of this on github - openCVSquares and openCVStitch. It's worth you taking a look, just to see how the C++ code is separated out from obj-C.
The openCV libraries have a C++ interface, so using C++ in the project is unavoidable. It would be possible to mash all of the code into .mm files, but that's an easy way to make a mess.
As regards portability, you get this by separating your UI code from your data-manipulation code. You should be doing this anyway for MVC, so it will be little additional work to write your model in C++ as per these examples. The model is portable, the UI is - and should be - platform specific.
Whether you should do this will depend on other factors such as your fluency with each language, the choice of frameworks and libraries, and the likelihood of porting. Audio processing would be a natural candidate for such an approach though.
Some detail about the samples
Don't worry if you can't get the code to run (the openCV framework can be troublesome...) the main thing is to see how the code is pieced together. I've tried to keep the examples very simple.
The C++ code was ported from C++ samples included with the openCV distro: squares.cpp and stitching.cpp. I tried to alter these as little as possible in order to assess this idea of portability.
Roughly, I had to address two issues...
1/ removed any UI code (so we are just sending data back to the obj-C side).
2/ modify the main() function so it becomes a callable function from the obj-C side. In the .cpp header file I declare a simple class with a single static function to facilitate this. Obviously there is scope to get much more elaborate but this should be enough for you to get the idea.
Assuming I am only using them for "normal" GUI programs (no COM, no ActiveX, nothing fancy), what is the fundamental difference I will see between ATL and MFC, to help me figure out which one to use?
I've done some searches on the web, but ultimately none of the answers really answered my question:
http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx:
"ATL is a fast, easy way to both create a COM component in C++ and maintain a small footprint. Use ATL to create a control if you don't need all of the built-in functionality that MFC automatically provides."
Doesn't really answer my question, because:
I'm not working with COM.
Does this imply MFC isn't fast? Why/how?
"MFC allows you to create full applications, ActiveX controls, and active documents. If you have already created a control with MFC, you may want to continue development in MFC. When creating a new control, consider using ATL if you don't need all of MFC's built-in functionality."
Also doesn't answer my question, because:
I don't really even know what ActiveX is in the first place.
It looks as though Microsoft is discouraging the use of MFC, but I can't figure out why.
What exactly is MFC's "built-in functionality" that ATL doesn't provide?
In general, this doesn't answer my question because it doesn't explain the downsides and the reasons behind them.
because directly or indirectly, everything seems to link back to the previous page:
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
"ATL & MFC are somewhat trickier to decide between. [[No kidding!]] I'd refer you to MSDN's page for choosing in order to decide between them."
Obviously, this doesn't answer my question. :)
http://www.codeguru.com/forum/archive/index.php/t-64778.html
etc.
What I have currently observed (within the last couple of days, while trying to learn both):
ATL is based on templates, or compile-time polymorphism.
ATL methods tend to be non-virtual, and tend to return references.
MFC is based on virtual methods, or run-time polymorphism.
MFC methods tend to be virtual, and tend to return pointers.
But there doesn't seem to be any architectural difference between them:
Both use message maps (BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP... big deal)
Both wrap Win32 methods into classes
Both seem to have similar classes CWnd vs. CWindow
But then, if there's no real difference except for the compile-time vs. run-time aspect, then why do both of them exist? Shouldn't one of them be enough?
What am I missing here?
I think the answer to your question is mostly historical, if you look back at how the two libraries originated and evolved through time.
The short answer is, if you are not doing anything "fancy", use ATL. It's great for simple user interfaces with COM thrown in.
The long answer:
MFC was built in the early 90s to try out this new language called C++ and apply it to Windows. It made Office like features available to the development community when the OS didn't have them yet.
[Edit embellishment: I did not work at Microsoft, so I don't know if Office was ever built on MFC, but I think the answer is no. Back in Win 3.1, Win 95 days, Office UI team would invent new controls, package them up in libraries, then the Windows and MFC teams would incorporate wrappers and API to those controls with redistributable dlls. I would guess there was a bit of collaboration and code sharing between those teams. Eventually those controls would make it into the base operating system in service packs or the next Windows version. This pattern continued with the Office Ribbon which was added into Windows as an add-on component well after Office shipped, and is now part of the Windows OS.]
At that time the library was quite primitive, both because of the C++ language and compiler being new, and Microsoft building it up over time as Office evolved.
Because of this history, MFC:
Has a fairly clunky design. It started as a light wrapper around the Windows API, but grew. There are a bunch of little 'features' that had to be invented because the compiler and language just didn't support them. There were no templates, they invented a string class, they invented list classes, they designed their own run time type identification, etc.
Encapsulates 20 years of Office and Windows evolution, which includes a whole crap load of stuff you will probably never use: Single and Multiple Document interfaces, DDE, COM, COM+, DCOM, Document Linking and Embedding (so you can embed a word document in your app if you wanted to), ActiveX controls (evolution of object embedding for the web!), Structured Document Storage, Serialization and Versioning, Automation (from early VBA years), and of course MVC. The latest versions have support for Visual Studio style window docking, and the Office ribbon. Basically every technology out of Redmond in 20 years is in there somewhere. It's just HUGE!
Has a ton of little gotchas, bugs, workarounds, assumptions, support for things that are still there that you will never use, and they cause problems. You need to be intimately familiar with the implementation of many classes and how they interact to use it on a decent size project. Delving into MFC source code during debugging is common. Finding a 15 year old tech note on some pointer being null causing a crash still happens. Assumptions on initialization of ancient document embedding stuff can affect your application in weird ways. There's no such thing as abstraction in MFC, you need to work with it's quirks and internals daily, it doesn't hide anything. And don't get me started on the class wizard.
ATL was invented as the C++ language evolved, and templates arrived. ATL was a showcase of how to use templates to avoid the run-time problems of the MFC library:
Message maps: Since they are template based, types are checked, and if you screw up the bound function, it doesn't build. In MFC message maps are macro based, and run-time bound. This can cause odd bugs, message routed to the wrong window, a crash if you have function or macro defined incorrectly, or just simply not work because something isn't hooked up right. Much more difficult to debug, and easier to break without noticing.
COM/Automation: Similar to message maps, COM was originally run-time bound using Macros, requiring lots of error handing and causing odd problems. ATL made it template based, compile time bound, and much, much easier to deal with.
[Edit Embellishment: At the time ATL was created, Microsoft's technical road map was mainly focused on 'Document Management'. Apple was killing them in the desktop publishing business. Office 'Document Linking and Embedding' was a main component to enhancing the 'Document Management' features of Office to compete in this space. COM was a core technology invented for application integration, and Document Embedding API's were based on COM. MFC was difficult to use for this use case. ATL was a good solution to make this particular technology easier for 3rd party's to implement COM and utilize document embedding features.]
These little improvements make ATL hugely easier to deal with on a simple application that doesn't need all the office like features of MFC. Something with a simple UI and some Office automation thrown in. It's small, it's fast, it's compile time bound saving you much time and headache. MFC has a huge library of classes that can be clunky, and difficult to work with.
Unfortunately ATL stagnated. It had wrappers for the windows API and COM support, and then it never really went beyond that. When the Web took off, all this stuff was sort of forgotten as old news.
[Edit Embellishment: Microsoft realized that this 'Internet Thing' was going to be big. Their technical road map changed drastically to focus on Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM in Distributed Transaction Server. So the Document Linking and Embedding was no longer a high priority.]
The huge footprint of MFC made it impossible for them to dump, so it still evolves slowly. Templates have been incorporated back into the library, as well as other language and API enhancements. (I had not heard of WTL until I saw this question. :)
Ultimately, which one to use is simply a matter of preference. The majority of the features you need are in the base OS API, which you can call directly from either library, if there is no suitable wrapper in the library.
Just my 2 cents based on using MFC for many years, and I use it now daily. I dabbled in ATL when it was first released on a few projects for a couple of years. It was a breath of fresh air in those days, but never really went anywhere. And then the Web came along and I forgot all about it.
Edit: This answer has surprising longevity. Since it keeps popping up in my stack overflow page, I thought I'd add some embellishment to the original answer I thought was lacking.
I have been told by many people who have used both that their programming experience was less painful with ATL than with MFC. Your compiled executable will also be much smaller with ATL.
I recommend you take a look at WTL, as it builds upon ATL.
What is that "extra functionality" they keep mentioning? Do I need it?
If you define your requirements, it might be easier to answer if you can avoid using MFC. Unfortunately "nothing fancy" isn't exclusive enough. Being inclusive as to which features you intend to use might be more helpful (which controls, which frameworks/technologies/existing libraries you want to use, etc).
But here's an article that describes some features in MFC that aren't directly supported by WTL/ATL.
MFC also has evolved to the point it supports a great many desirable features, such as MAPI, support for the other Windows logo requirements, sockets, documents (if you like and/or use that pattern), and compound document files. WTL has its share of cool features, but MFC is the clear feature champ. Both environments support framed main window architectures (frame window with separate view window), SDI and MDI applications, split windows, dialog-based applications, and various COM-based classes for COM support.
ATL is a set of classes meant to simplify the implementation of COM objects.
You can use it without MFC. At my job, we use ATL to expose COM interfaces to computational code. There is no GUI involved, it is for us to be able to call this computational code from eg. Excel VBA.
Look at some COM guide/tutorial to see what it abstracts.
MFC is just a set of GUI wrapper classes to the Win32 API. Look at some Win32 API tutorial to see what it abstracts.
I have a pre-existing c++ object model which represents the business layer tier of an application. I want to be able to expose the object model to applications written in other languages i.e vbscript, VB, javascript etc. I believe the best way of doing this is to wrap the business objects with a COM layer.
What fast and effective methods are there for doing this. Any advice, links to practical "How to" documentation would be very much appreciated.
Because I'm starting a bounty on this , here's a few extra guidelines for potential bounty hunters :-
1)I've decided on an ATL approach
2)I'm now specifically looking for links to really good "how to and quickly" documentation on wrapping a pre-existing c++ object model to make it useable by a scripting language like javascript
3) Something with small working examples showing me what code needs to be added to what files, e.g what goes into the cpp , idl and hpp/h etc. It' must include an example I can compile test and change to get a better understanding.
Addendum .....
Further context. For me this is a re-visit to COM after about 10 years. I did MFC and ATL COM for the 3 years prior to 2000. I understand what COM is , the principles used to implement it in C++, threading models etc. Any "how to and quickly" documentation will not be leading me blindly and glazing over important principles, more it'll be a guided re-learning experience.
If I had more time I'd dig into "developer's workshop to COM and ATL 3.0" by Troelsen, a very good book but it's a very slow kick (re)start.
Further context following comments...........
Keeping it as simple as possible , Single-Threaded Apartment model and an inprocess dll.
I find a good collection of articles for beginner in http://www.codeproject.com/KB/COM/index.aspx?#COM/DCOM/COM+%20-%20Beginners. This are:
http://www.codeproject.com/KB/COM/hellocom.aspx, http://www.codeproject.com/KB/COM/comintro2.aspx,
http://www.codeproject.com/KB/COM/comintro.aspx, http://www.codeproject.com/KB/COM/com_server_without_mfc_atl.aspx, http://www.codeproject.com/KB/COM/com_in_c1.aspx
But if you start to program a COM objects it's very important to understand threading models of COM. This is explain very good here
http://www.codeproject.com/KB/COM/CCOMThread.aspx, http://www.codeproject.com/KB/COM/CCOMThread2.aspx
But I decide to answer you because I want suggest to choose a little other modern way. COM technology is very old. Dot NET has all the features inside and will permanently developed. So I find an approach from Building COM Servers in .NET the most interesting. You write your COM full in C# divide the development of your COM objects in two parts:
You write interface only assembly without any implementation and register it.
You develop a .NET classes which implements this COM interface.
You can look at the more easy version of the same in http://www.codeproject.com/KB/COM/COMinDotNet.aspx, http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx, http://msdn.microsoft.com/en-us/library/ms973807.aspx, but I recommend you the way "Building COM Servers in .NET" described in http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx.
UPDATED after the comment: Sorry, but you are searching an easy way to solve a complex problem. It is impossible.
It is very important to understand, that despite of quasi similarity there are a lot of principal differences between object oriented C++ and COM. It’s important to understand, that COM isn't an object-oriented language but a binary protocol. A software component (COM objects) is a binary unit of reusable code. It solves a lot of problems existing in separate compilation of modules of programs designed based on object-oriented approach.
If, for example, somebody inherited you classes and you change later some private members, it makes influence to the all inherited classes. The full code used your C++ objects must be recompiled at least because sizeof(object) has been changed. Such problem not exists in COM, because all who use your objects don’t inherit your object classes. One uses your objects through interfaces, which signature and sizeof() will not be changed after you modify some private members of your base classes. You can read online some very good examples in the first chapter of the classic book "Essential COM" by Don Box: http://books.google.co.uk/books?id=kfRWvKSePmAC&dq=essential+com&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=6&ct=result. I recommend you also to read a small article http://edndoc.esri.com/arcobjects/9.0/ArcGISDevHelp/DevelopmentEnvs/COM/IntroToCOM.htm to understand more differences between COM and C++ objects.
If you rewrite your C++ objects as a COM objects you have to choose threading model, you have to understand how to write a thread safe program or you have to use Single-Threaded Apartment model. All your objects will be exist (allocated and running) in a separate thread. If you choose Out-Of-Process COM object (an exe with all your objects will be created), then a new process will be created. If somebody calls a method of your object a marshaling of all parameters will be done. Marshaling of parameters means allocation of memory in another thread and copying of all parameter to the thread.
All this things which I described before are not a terms of C++ objects. I write this only to clear that COM really not the same as C++ object model.
So to wrap your existing C++ objects you have to define some pure virtual classes – interfaces which you implement in your objects. This interface must be in written in IDL/MIDL (Microsoft Interface Definition Language). This is the most important thing! Then you have to implement these interfaces as COM coclasses using your existing C++ classes.
I am sure if you do these work in .NET you have not be required to study a lot of implementation details typically needed to know for COM developer. You just define an Interface in C#/C++ (a pure virtual class) and compile it. You can generate a private key for strong signed assembly inside of Visual Studio. Just go in the project settings in "Signing" part and select "Sign the assembly" then choose "New" strong name key file. It’s all. With this way you full define a COM interface. A MIDL version of the interface will be generated for you.
Then you create a new project in C# or C++ and declare classes which inherit the interface which you define before. During implementing of this interface you can use your entire existing C++ object. So you will be able quickly rich your targets. Just follow the way described in details in http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx. With this way you will not have to study a lot of technical details which you have to know for classical COM implementation in C++. And you will study a modern .NET instead of studying the old and de facto dead (or not further developed) COM.
Sorry for the long answer.
http://www.lambdasoft.dk/Comet/index.htm
Comet is language binding between COM and C++. It allows you to do both COM client and COM server programming, without any dependency on either ATL or MFC. In other words Comet is a replacement for ATL.
Plug-in systems in C++ are hard because the ABI is not properly defined, and each compiler (or version thereof) follows its own rules. However, COM on Windows shows that it's possible to create a minimal plug-in system that allows programmers with different compilers to create plug-ins for a host application using a simple interface.
Let's be practical, and leave the C++ standard, which is not very helpful in this respect, aside for a minute. If I want to write an app for Windows and Mac (and optionally Linux) that supports C++ plug-ins, and if I want to give plug-in authors a reasonably large choice of compilers (say less than 2 year old versions of Visual C++, GCC or Intel's C++ compiler), what features of C++ could I count on?
Of course, I assume that plug-ins would be written for a specific platform.
Off the top of my head, here are some C++ features I can think of, with what I think is the answer:
vtable layout, to use objects through abstract classes? (yes)
built-in types, pointers? (yes)
structs, unions? (yes)
exceptions? (no)
extern "C" functions? (yes)
stdcall non-extern "C" functions with built-in parameter types? (yes)
non-stdcall non-extern "C" functions with user-defined parameter types? (no)
I would appreciate any experience you have in that area that you could share. If you know of any moderately successful app that has a C++ plug-in system, that's cool too.
Carl
Dr Dobb's Journal has an article Building Your Own Plugin Framework: Part 1 which is pretty good reading on the subject. It is the start of a series of articles which covers the architecture, development, and deployment of a C/C++ cross-platform plugin framework.
You might also want to consider replacing the conventional plugin interface by a scripting interface. There are some very good bindings for several scripting languages in C/C++ that have already solved your problem. It might not be a bad idea to build on top of them. For example, have a look at Boost.Python.
Qt has a very nice system for plugins that I've used in the past. It uses Qt's meta-object system to overcome many of the problems typically found when trying to develop C++ plugins.
One example is how Q_DECLARE_INTERFACE works, to prevent you from using an incompatible plugin. Another is the build key, to make sure you load the correct plugin for your architecture, OS, compiler. If you don't use Qt's plugin system, these are things you will have to worry about and invent solutions for on your own. It's not necessarily rocket science, and I'm not saying you'd fail at it, but the guys at Trolltech are pretty smart and have spent a while thinking about it, and I'd rather use what they created than reinvent the wheel myself.
Another example is that RTTI typically doesn't work across DLL boundaries, but when using Qt, things like qobject_cast which rely on the meta-object system do work across DLL boundaries.
I think you are safe creating a plugin system based on:
Packaging of plugin functionality into library (.dll, .so, etc.)
Requiring that the plugin expose key C-language exports.
Requiring that the plugin implement (and return a pointer/reference to) an abstract C++ interface.
Probably the most successful C++ plugin system: good old Adobe Photoshop. And if not that, one of the virtual synth formats such as VSTi etc.
The book Imperfect C++ by Matthew Wilson has a nice info about this.
The advice in the seems to be: as long as you use the same (or equivelant) compiler, you can use C++, otherwise you're better of using C as an interface on top of your C++ code.
I have my own game engine that has a C++ plug-in system.
I have some code in header files so it gets put into the plugin's compilation unit.
Larger functions that live in the main engine are called via an exported C function (plugin calls MyObject_somefunction(MyObject *obj) which in the engine just calls obj->somefunction()). If calling a C function is ugly for your taste, then with some header trickery, when the header is included in the plugin, have the member function #defined to call the C function:
#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif
Virtual functions either have to be pure or the code lives in the header file. If I'm not inheriting from a class and merely just instancing one, virtual function code can live in the engine, but then the class must export some C functions for creating and destroying the object that is called from the plugin.
Basically, the tricks that I have used, with the goal being to maintain total platform independence, just amount to C exports and header file tricks.
ACE has a cross platform plug-in architecture.
Check out:
ACE DLL
ACE DLL Manager
I would suggest checking out the book
The ACE Programmer's Guide
Firefox runs on XPCOM (http://www.mozilla.org/projects/xpcom/). It's inspired by Microsoft COM but it's multiplatform.