Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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++?

share|improve this question
C# is also a very powerful language. – Adam Crossland Feb 14 '12 at 18:33
@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 Feb 14 '12 at 18:34
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 Feb 14 '12 at 19:17
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#. – David Thornley Feb 14 '12 at 21:12
@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 Feb 15 '12 at 11:07
up vote 16 down vote accepted

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 two bundled managed languages, C# and VB.NET.

share|improve this answer
+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. – Igor Soloydenko Feb 14 '12 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." – Jesse C. Slicer Feb 14 '12 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. – Igor Soloydenko Feb 14 '12 at 22:11
Last time I wrote some C++ was literally sometime in the last century :) – Jesse C. Slicer Feb 14 '12 at 22:22
@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 Feb 15 '12 at 9:33

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.

share|improve this answer

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.

share|improve this answer
I do not agree with this statement. C++/CLI is perfectly suitable for many implementations. – Ramhound Feb 14 '12 at 18:29
@Ramhound: Microsoft themselves only recommend it for interoperation. That's their official policy. – DeadMG Feb 14 '12 at 18:34
@DeadMG can you provide a source for that? – sq33G Feb 15 '12 at 8:24
@DeadMG, you're wrong. There are so many options of running .NET GUI with a native logic. – SK-logic Feb 15 '12 at 9:26
@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 Feb 15 '12 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 the source code you wouldn't have to recompile it 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.

share|improve this answer
But when P/Invoking C++ directly, be aware of mangling, or better provide a thin C wrapper in between. – SK-logic Feb 15 '12 at 9:31

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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