C+++/CLI Vs WIn32API COM

[revantj]

Hello,

I basically am writing a Video Conference Program. Now I'm developing the main functions in WIn32API and GUI is accomplished by C#. So I was looking into converting my Win32API routines into C++/CLI.

Basically what I want to ask is what is the advantage of using C++/CLI as opposed to using WIn32API COM and pInvoke. From what I've heard the syntax in C++/CLI are tedious to say the least. Are there anythings that can be accomplished in C++/CLI that are not possible by just using Win32 COM object and pInvoke.

Thanks

[Zaccheus]

From the point of view of what you do, I find pure verifyable C++/CLI is actually much closer to C# than it is to ANSI C++ Win32/COM.

C++ with managed extensions was very tedious, but C++/CLI is a .net language in its own right (see the two links in my signature). So the main advantage of using C++/CLI is that you have access to all the benefits of the .net world.

If you are at home with IDL and type-libraries, it is very easy to automatically create .net wrapper DLLs which let you use your existing COM objects from any .net language.

Apart from re-using existing tested code, I think there is little point in creating mixed assemblies or even using p/invoke - unless you have very special requirements. While I can see many reasons for choosing C++/CLI over C#, I'm finding less and less reasons to continue with native Windows development part from a few very specialised components.

[revantj]

Thus would you say C++/CLI has access to both native win32api functionality as well as the .NET framework ?

[Zaccheus]

Yes, but so does C#.

There are two ways of accessing native win32api functionality.

1) MIXED MODE, also known as interop: Native and managed code in the same DLL. You can only do this with C++ (i.e. native ANSI C++ with managed C++/CLI). I personally don't like it because it means some of your native code is dependent on .net and some of your managed code cannot be verified/profiled/unit-tested with the usual .net tools. I prefer to keep native DLLs completly native and managed DLLs completely managed. But that's just me, others love mixed mode.

2) P/INVOKE. You can do this from just about any .net language, including C# and C++/CLI. You specify an exported function's signature in terms of .net types and you specify the name of the DLL which contains that function. This is very much like a normal DLL import declaration. The .net framework transforms the parameters into the native equivalents when the function is called. Thus you can call Win32 API functions like GetPrivateProfileString. Of course there is a slight overhead as the parameters are translated for each function call.

[Zaccheus]

A few helpful links:

Platform Invoke Tutorial (for C#, but also applies to C++/CLI)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vcwlkplatforminvoketutorial.asp

The .net signatures of almost all Win32 API functions:
http://www.pinvoke.net/

Accessing COM objects directly from .net:
http://msdn2.microsoft.com/en-us/library/xwzy44e4(VS.80).aspx

Using C++ Interop (mixed mode)
http://msdn2.microsoft.com/en-us/library/2x8kf7zx(VS.80).aspx