I've read many comments about GUI programming, in both, C# and C++. And I noticed that Microsoft's .NET framework is powerful for GUI programming. So is it possible to use C++ and .NET framework?

I think it will be a great combination since C++ is powerful language, and .NET framework is preferred for GUI programming on Windows, as I've read. Is it possible to write the GUI in C# and the functionality in C++?

  • 8
    C# is also a very powerful language. Commented Feb 14, 2012 at 18:33
  • 2
    @Ramhound: It's not true at all that C++/CLI is as powerful as C#. C++/CLI code contains all the optimizations from the C++ compiler and can execute faster, and still contains many metaprogramming and preprocessor techniques that are not in C#.
    – DeadMG
    Commented Feb 14, 2012 at 18:34
  • 2
    Plus, it shouldn't be any challenge to pick up C# if one is good at C++. I'm not saying but I'm saying.
    – Rig
    Commented Feb 14, 2012 at 19:17
  • 4
    Given that you know C++, you would have a choice between learning C++/CLI or C#. Neither is actual C++. I'd suggest learning C# rather than attempting to work with C++/CLI; C++/CLI is not a native language anywhere, so you'll find a lot of books and support for C#. Commented Feb 14, 2012 at 21:12
  • 6
    @ddacot no, C++ is not meant for game development at all. It's meant for software development, just like all other programming languages. Games just happen to be one kind of software.
    – MattDavey
    Commented Feb 15, 2012 at 11:07

6 Answers 6


Yes, it's formerly known as Managed C++ and now C++/CLI. You have access to the entirety of the .NET Framework (GUI: WinForms, GDI+, etc.) as you would from the other three bundled managed languages, C#, F# and VB.NET.

  • +1 To Jesse's answer. If I am not mistaken, C++/CLI doesn't support multiple inheritance. So, be prepared to some unexpected features. Some of these features came from limitations of the CLI. I recommend you trying to find difference between C++/CLI and 'classic' C++ before you start using it. Commented Feb 14, 2012 at 21:49
  • This is mentioned in some detail in the first link. The summary is thus: "C++ has evolved much over time and most software written in the language is object oriented. Managed C++ and the use of classes and class based objects remains prevalent like in Visual C++. The only major change to this in Managed C++ is that the capabilities of multiple inheritance are not supported. This is because of a limitation of the CLR. A class managed under the CLR's garbage collector cannot inherit more than one class." Commented Feb 14, 2012 at 21:58
  • That's OK. Actually, I'm not good in C++. I just thought that there can be another important differences which can make problems. Commented Feb 14, 2012 at 22:11
  • Last time I wrote some C++ was literally sometime in the last century :) Commented Feb 14, 2012 at 22:22
  • 3
    @keykeeper, a typical use of C++/CLI is to be a thin bridge between an unmanaged C++ library and the managed world. It is sufficient for such a use. Of course it does not make sense to code something sizeable in it.
    – SK-logic
    Commented Feb 15, 2012 at 9:33

Do not forget about the most flexible and simple option, a typical for Unix world but, for some reason, not that common in Windows: splitting GUI and logic into different processes, communicating via any reasonable form of RPC (e.g., even a pipe should work). Preferably with a simple, human-readable text protocol.

This way you can implement you GUI (or various GUIs) with any technologies you fancy, and build up logic components from whatever suits the need better - C++, scripts, whatever else.

I'm not aware of any reasonable advantages of a monolithic design approach from the Windows world.


I did this once a few years ago, back in the days of Managed C++. We had some business logic in an umanaged DLL that we wanted to incorporate into a wizard-style GUI written in C#. To do this, I created a Managed C++ assembly to sit between the managed GUI app and the unmanaged DLL and used System::Runtime::InteropServices::Marshal within that assembly to convert values from managed types (System::Int32) to unmanaged types (int) and vice versa.

While Managed C++ appears to be deprecated, the same principal might apply to C++/CLI.


Not really. There is a hybrid language C++/CLI, but it's only good for interoperation (Microsoft's official policy). Because of the way the .NET framework is designed, there are many language semantics which really don't fit running on the CLR, and C++ exhibits many of them.

  • 7
    I do not agree with this statement. C++/CLI is perfectly suitable for many implementations.
    – Ramhound
    Commented Feb 14, 2012 at 18:29
  • 3
    @Ramhound: Microsoft themselves only recommend it for interoperation. That's their official policy.
    – DeadMG
    Commented Feb 14, 2012 at 18:34
  • 2
    @DeadMG can you provide a source for that?
    – sq33G
    Commented Feb 15, 2012 at 8:24
  • 1
    @DeadMG, you're wrong. There are so many options of running .NET GUI with a native logic.
    – SK-logic
    Commented Feb 15, 2012 at 9:26
  • 2
    @DeadMG - Unless you provide proof that thats Microsoft's official policy ( I don't believe that for a minute ) then your just passing around FUD
    – Ramhound
    Commented Feb 15, 2012 at 15:48

The C++/CLI angle has been covered by plenty of answers so far, but another way of doing this is to use PInvoke. This allows C# programs to call functions contained in dlls that were written in C++. The advantage of PInvoke is that your dll is totally agnostic about the fact that it will be called from .Net. This means you can call dll's for which you have no source code, and even if you did, you wouldn't have to recompile the source code using the /clr option. This means you can use this dll with other C++ programs, as well as C# programs. There are some fantastic C/C++ libraries out there: PInvoke allows you to take advantage of these. Sometimes Win32 libraries provide functions that just aren't available in .Net: PInvoke allows you to use them.

One of the trickiest parts of using PInvoke is knowing how to convert the unmanaged signature to a managed signature. But there is a cheatsheet to help with that.

  • But when P/Invoking C++ directly, be aware of mangling, or better provide a thin C wrapper in between.
    – SK-logic
    Commented Feb 15, 2012 at 9:31

You can also work with a C# dill via COM (Component Object Model). For me COM was better then using Managed C++ since Visual Studio 2010 doesn't have intellisense for Managed C++. In my case we already have a large C++ application but wanted to try to move away from MFC to WinForms or WPF.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.