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.

Comments

• Anonymous
  November 21, 2005
  One big step that the VC++ team should take is to impress upon the XAML team that they need to support C++. I don't see people using C++ to write Avalon apps if they can't take advantage of XAML designers. No one in their right minds would want to use procedural code to develop complex UIs.

• Anonymous
  November 21, 2005
  You should use CodeDom to generate all your example code in API documentation. I'm not kidding.
  
  I don't use C++ but it's utterly silly to have a cross-language API where the documentation favors one language over another. And it's even more ridiculous when the technology exists to produce language-neutral sample code.
  
  Ok, perhaps in today's world it would be a little painful to construct the CodeDom manually for a given chunk of sample code, but isn't xaml supposed to make it extremely easy to construct an arbitrary hierarchy of objects? It wouldn't be too hard to write a little program that would load a chunk of xaml defining a CodeDom statement block or class, and then serialize that to an arbitrary language.
  
  The promise of .NET is that all languages are equal, and it would be really instructive to start seeing samples in Eiffel# and F# and Nemerle and IKVM-java and, yes, C++, as well as VB and C# and JS...

• Anonymous
  November 21, 2005
  Nishant, I would ask the question this way: Why couldn't you build your UI in C# and use C++/CLI to tie it to a native or managed business layer? I'm not saying this is necessarily the plan; I'd just really like to hear why you'd really prefer to use C++/CLI over C# in this scenario.
  
  Stuart, I think using CodeDOM to automatically translate examples could help, although they would probably still require a good bit of hand-editing since information is almost always lost in the translation.

• Anonymous
  November 21, 2005
  > 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.
  
  You are mismeasuring the benefits.
  
  Less than 1/20 of Microsoft customers use development tools.
  
  Less than 1/20 of Microsoft development tools customers use the DDK.
  
  Less than 1/20 of commercial applications use the .Net framework.
  
  Nonetheless everyone is going to depend on how these tools perform.

• Anonymous
  November 22, 2005
  Steve, you missed my point: I wasn't suggesting using CodeDom to translate examples since that suggests going from one language to another. I was suggesting that the examples are written directly in CodeDom (using xaml, specifically, although we could imagine other ways of solving the problem of generating a tree of CodeDom objects) so that the raw source is free of language-specific content.
  
  At least for CLS-compliant APIs, there should be no need for anything that can't be expressed in CodeDom. Which means that there's nothing to be "lost" in the translation: if a language supports CodeDom it must provide a way to express all the constructs that CodeDom can create. The examples may not end up as idiomatic C++ or F# but they should always end up as code that would compile and do the same thing as the same CodeDom emitted as C#.

• Anonymous
  November 22, 2005
  Thanks for the detailed reply. I suppose what really bothers me the most about this situation is the disconnect between the marketing hype for .NET and the reality. It's like the propaganda for the "platform independence" of Java - you can indeed "write once, run anywhere" just so long as the JVMs work the same, which they often don't. Sinilarly, .NET is "language independent" just so long as the same .NET libraries are available in all languages, which they sometimes aren't (in the cases mentioned in your discussion, such as Web forms).
  
  Will users be able to incorporate Indigo - excuse me, WCF - into their C++ code? I'm asking because I really don't know. I very much hope they can do that, because if .NET is indeed to be the new DCOM (among other things), then C++ support would certainly seem to be important.
  
  I fear that the solution will be, as you suggest above for Avalon / WPF, "Why couldn't you build your UI in C# and use C++/CLI to tie it to a native or managed business layer?" Obviously, there's nothing inherently wrong with doing that, and in fact it's what most C++ developers are doing now (out of necessity rather than out of conviction). Again, it's just that having to do so makes the claim that C++/CLI is a "first-class .NET language" a rather shallow one. Any language that has to be wrapped in another language in order to do anything useful (such as GUI development, which was certainly a principal application of Visual C++ / MFC), is at best a "second-class" language, pretty much by definition.
  
  Again, sorry for the rant, and keep up the good work (honestly!).

• Anonymous
  November 22, 2005
  Hi Norm,
  
  >>
  You are mismeasuring the benefits.
  Less than 1/20 of Microsoft customers use development tools.
  Less than 1/20 of Microsoft development tools customers use the DDK.
  Less than 1/20 of commercial applications use the .Net framework.
  Nonetheless everyone is going to depend on how these tools perform.
  <<
  
  Those made-up numbers were written from the perspective of a manager running the web forms team. If you're that person, 100% of your customers use development tools, 100% of your customers use .NET, and 0% of your customers are using the DDK to solve the business problem you're trying to solve.
  
  -steve

• Anonymous
  November 22, 2005
  Hi Staurt,
  
  Translating them or writing them in XAML kind of gives you the same thing: almost-there samples that still need to be hand-tweaked to ensure the code conforms to specific language conventions, nuances, best practices, etc. I still think it's a good idea that could save potentially some time, though.
  
  -steve

• Anonymous
  November 29, 2005
  The comment has been removed

• Anonymous
  December 05, 2005
  Peter,
  
  I replied here: http://blogs.msdn.com/texblog/archive/2005/12/05/500263.aspx
  
  -steve

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/735557-is-there-any-reason-to

• Anonymous
  June 02, 2009
  PingBack from http://woodtvstand.info/story.php?id=43810