Is C++ a first-class .NET language?

I get this question pretty frequently.  Most recently, reader Wil brings it up in response to my last blog post.  It's a very fair question; we keep talking about how cool C++/CLI is, but there is no denying that several of Microsoft's tools and technologies support only C# and VB.  I'd like to take the opportunity to discuss Wil's points...

"I keep **hearing** that C++/CLI is a first-class CLI language, but does it in fact occupy the same elevated status for .NET development as the C#/VB.NET language (which I count as one, since it's largely the same language with 2 different syntaxes)? For instance, to work with the Visual Studio Tools for Office you will have to use C#/VB. What about Web Forms, Indigo/WCF, etc.?"

I first want to distinguish between the C++/CLI language extensions and the degree to which other tools and technologies may support C++/CLI.  No, it's not what you think; I'm not trying to be weasely here.  Hear me out.

Our first cut at .NET support in C++, Managed Extensions, wasn't -- to phrase it charitably -- first-class.  It was important to us on the VC++ team to ensure that VC++ be a first-class .NET language in Visual Studio 2005.  I think we accomplished that, and perhaps more.  Not only does C++/CLI surface the full scope of CLR capabilities found in C# and VB.NET, but it goes much further in allowing one to leverage standard ISO C++ language features and libraries and efficiently mix native and manage code and easily interoperate between the two.  Even from a pure CLR standpoint, C++/CLI has some distinct advantages over other C# and VB.NET, such as deterministic destruction, stack semantics for managed classes, and superior optimizations.

The tools and technologies side is a different story.  You point out, for example, that C++/CLI isn't supported by technologies like VSTO and ASP.NET web forms.  How can this be if C++/CLI is a first-class .NET language and equally or better .NET-capable than C# or VB.NET? The short answer is that each product team is responsible for investing their resources to do the greatest amount of good for the greatest number of users in their market.

To illustrate, let's pretend that I run the web forms group.  If my product team tells me that supporting C++/CLI will take 20% of my total budget, but my research tells me that it's likely that only 5% of my user base will use C++/CLI, I have to decide whether it's worth investing 1/5 of my resources into a feature that will benefit 1/20 of my users.  The answer is: probably not.  Of course, these numbers aren't real; I'm totally making them up off the top of my head for illustrative purposes.  I'm also oversimplifying the problem a bit, but I think you get the idea.

You can also look at this problem from a C++-centric point of view.  Another game of make believe: Let's say the VB.NET team comes up with a cool language feature and the C# team decides to support it as well.  The VC++ team looks at this feature and sees that it's 10x the effort to put this feature in C++/CLI than it is to do it in VB.NET or C# (another made up number, but language features typically do require more effort to implement in C++).  If you manage the C++ team you have a choice: do you devote resources to that effort for the sake of "language parity" or do you instead use those resources to invest in one or more areas that you expect to solve the your specific customers' problems and/or are likely to delight a greater portion of your user base? My personal view is that advancing all languages in lockstep along a broad front is not the right thing to do.  Each language should be free to innovate in its own space, and the other languages can draft off of the successful innovations and adopt those features that make sense for their own users.

Finally, there is the simple, pedestrian issue that C++/CLI was just release last week, so it's somewhat understandable that some of the new or in-development technologies would hesitate to take a dependency on C++/CLI until it is released.  Now that it is, I do believe you'll see more broad investment in C++/CLI in other Microsoft technologies going forward.

Hopefully that provides some insight into why things are the way they are.  Now the issue becomes: if you believe with are under-investing in C++ in certain areas, what can you do about it?  Tell us.  Comment on the blogs.  Submit feature requests via MSDN Product Feedback.  We really do listen to this stuff.

"The original question was about sample code - just check out all the MSDN documentation for .NET (version 1, as well as Vista's pre-beta eye-candy) and see how many examples are given in C++ vs. how many in C#/VB. Go to the MS Press site and see what books are coming out on .NET v2, WPF, WCF, etc. (to say nothing of the books about the languages themselves!) and see what MS authors expect .NET programmers to use."

In a perfect world, each conceptual example would be available in all .NET languages.  That said, I agree that there are comparatively fewer C++/CLI examples in our docs, and this is a problem.  Luckily, it's a problem we're aware of, so we're trying to improve in this area.  Again, C# and VB.NET have a head start on us here, since C++/CLI is new, but we'll keep working on it.

Regarding books, to be fair, there are more developers out there doing .NET development with C# and VB.NET, so it stands to reason that the book market would meet the greater need there.  However, if there are specific C++/CLI topics on which you're trying to find books, etc. but cannot, do let us know.

"For all the talk about .NET's being language-neutral, it appears that some languages' CLR is more equal than others. C++ is still treated mainly as an interop tool with .COM rather than a truly first-rate vehicle for building pure .NET apps, it seems to me. Or am I missing something? I surely hope so, because using the same language for both managed and unmanaged code is certainly an appealing prospect."

I don't think I'd quite agree with that assessment.  First of all, let's not sell native code and COM interop short; it's a big deal, and it's one of the things that VC++ is really good at that other .NET languages are not as good at.  I do think it's fair to say that C++/CLI is indeed a first-class CLR language.  However, I'm inclined to agree that C++/CLI doesn't enjoy the same level of first-class support for various .NET tools and technologies that C# and VB.NET enjoy today.  Some of this is because C++/CLI is still new, some of it is by design, some of this is because we haven't gotten a chance to do the work yet, and some of this might be because we're getting it wrong in certain areas.  I can't say we'll be able to do everything you'd like on the schedule you're prefer, but I can say that the more we talk about it, the more we'll learn and the more closely the product will meet your needs.