I've recently been working with a team that's using both .NET C++ and pre-.NET C++.

I fully understand the technical differences between the two technologies. However, I sometimes feel like I'm floundering when it comes to the terminology used to differentiate the two.

Example: Say we have two projects:
ProjectA contains "C++" code that builds a .NET assembly DLL.
ProjectB contains Visual C++ code that builds a traditional native Windows DLL.

What is the best way to succinctly and terminologically draw a distinction between the two projects? Again, I'm not asking for an in-depth technical description of the differences between the two technologies. I'm just looking for names and labels.

This is how, today, I might try to make the distinction when talking to someone:

"ProjectA is a managed .NET C++ project"
"ProjectB is an unmanaged native C++ DLL project."

However I am not at all certain that this terminology is ideal, or even correct. Please describe what you feel the ideal language to use in this situation (or similar situations) might be. Feel free to motivate your answer.

  • 7
    To be pedantic, "Visual C++" doesn't refer to any programming language -- it's the name of Microsoft's IDE. That's like saying "notepad file" instead of "text file" Commented Jan 4, 2011 at 0:43
  • 3
    @Note - many folks say "Visual C++" when they refer to code with dependencies on MFC, ATL, and even windows.h (typedefs etc) that will almost certainly not compile anywhere else. Commented Jan 4, 2011 at 15:56

3 Answers 3


I would use "C++/CLI" to refer to the managed assembly, and just "C++" (or "native C++") to refer to the other.

C++/CLI is the "official" name of Microsoft's dialect of C++ that supports .NET, so it seems to make sense to use that.


Be aware that some native C++ developers (including ones I know on the Visual C++ team) do not care for the word "unmanaged" - it suggests that managed code is the default. Many C++ developers see the older and still vibrant native code as the default, and managed code as the variant. With that caveat, use either "native" or "unmanaged" for C++ that makes a traditional Windows DLL or EXE (or LIB, for that matter), and C++/CLI for C++ that makes a managed assembly to run under the CLR. Try not to say Managed C++ unless you mean that thing with the double underscores that we try not to talk about (you almost certainly don't.) Try also not to say C++-CLI or other strangely punctuated variants.

And while you're at it, for your native C++ you might want to start distinguishing between C++0x and older C++, or whether you're using MFC, ATL, or the newer no-MFC approach, plus whether you're into STL or even the template meta-programming stuff.

There are lots of flavours of C++. That's why it's been so successfull. :-)

  • 3
    One problem I have with "unmanaged" vs. "managed" C++ is that it seems to set up two equal versions, rather than C++ and a special-purpose variant. Also, the term is pretty much meaningless on a non-MS Windows platform. Commented Jan 4, 2011 at 15:24

This is the terminology I'd use:

ProjectA builds a managed Assembly; project B builds an unmanaged Assembly.

It's the cleanest way to differentiate between the two.

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.