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 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.

share|improve this question
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" – Note to self - think of a name Jan 4 '11 at 0:43
@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. – Kate Gregory Jan 4 '11 at 15:56
up vote 18 down vote accepted

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.

share|improve this answer

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. :-)

share|improve this answer
Great advice, Kate. Thanks for the exposition. – Mike Clark Jan 4 '11 at 5:44
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. – David Thornley Jan 4 '11 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.

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.