A Reader Bleakly Asks About the Future of C++ within Microsoft

A reader writes


Sender: Brian Braatz


I posted the following to the boost email group and receieved the following response. I was wondering if you had any comments or thoughts on this. I am personally concerned that MS will eventually ditch C++ or take away my ability to use ALL the features of the C++ lanuaguage (not now, but I feel it is coming.. someday I will have C# or VB.net as my only "choice" on the ms platforms)


There is no question that the original Managed Extensions for C++ was a severe body blow to the credibility of a viable future for C++ on the Microsoft platform. In fact, when I originally interviewed here, I said pretty much the same thing as Brian to the folks here, and it felt, anyway, that I spent much of the first half year here battling people’s perceptions that the managed exceptions while not perfect were pretty much ok. In some ways, the original release infuriated me; and that made me a less effective force for change than I might have been. It was clear to me from the outset that we had to either radically reengage our C++.NET vision or else pack up our tent and become a historical curiosity to an increasingly dynamic programming environment – something I would characterize as a tragically hopeful monster. Eventually, the whole department became mobilized; although it wasn’t until Herb Sutter took a leading role that we turned the corner, in my opinion. And I believe we have. The problem now is overturning nearly two years of being the .NET whipping boy and getting people to take us seriously – well, not us but the language, which is now called C++/CLI, and is both an ongoing ECMA standard and in liaison with the new ISO-C++ committee work. I personally guarantee that anyone that feels passionate about C++ will be both delighted by and engaged with the C++/CLI language that will be shipped with Visual Studio 2005, and should be available as a first peek in an upcoming Beta program. (I’ll engage more on the details in subsequent blogs – really J)

Comments (13)

  1. Eric says:

    Don’t know if Scoble will get ahold of this or not, but it’s this blog that has convinced me that C++ should continue to be a maintained part of my skill-set rather than being left behind in favor of the "rest" of the framework. I had pretty much written off managed C++ after the initial releases, but reading about the why and how of the new version has given me great hope.

  2. Albert says:

    MCPP is ugly but it is an incredibly useful tool when you have 6 millions of lines of unmanaged C++ code like we do and you want to start using the framework capabilities gradually. MCPP is till much better than having to write explicit P/Invoke signatures to interface the legacy code. It is excellent to see that we will be able to use C++ not only as "wrapping" language but also as a first choice for new .NET code.

    I can’t wait to see that beta!

  3. Jeff says:

    Here’s a suggestion – before inventing a new C++ language variant, how about making Visual C++ compliant with existing standards first, namely C99? Grumble…

  4. Erik Brendengen says:

    Will there be a public beta for this? Or do I have to wait until 2005 🙁 I would guess so.

  5. Stan,

    i think Albert is right with his comments on the way mc++ is _very_ useful for integrating c++ code.

    would be nice if ‘ijw’ (it just works) wouldn’t be a marketing term only.

    concerning the language: i, for one, have changed from beeing an active c++ developer to beeing a c# guy. there are _some_ things in c++ that i like better, however, given the current state of affairs in the ide space – c# is just soooo much more efficient to work with…

    maybe the 2005 code will change things – but, at least for me, that will be much too late to switch back…


    thomas woelfer

  6. Richard Hsu says:


    Would you suggest, for those of us who are yet to begin learning MC++, to wait till C++/CLI ships, because we’ll not only be learning what will be obsolete syntax, but also a more difficult one.

    So, would you recommend, till the release of C++/CLI compiler, it may be a better idea to use Interop in C# than go for MC++ as a temporary measure.



  7. J. Daniel Smith says:

    I think I’m starting to agree with Thomas Woelfer that C++/CLI will be "too little, too late" (well, probably not "too little"). This situation was exacerbated with the release slipping into 2005.

    C# works great in the IDE (large amounts of C++ code in .h files? Yuck!) and there are far fewer "gotchas" in the language than C++. C# makes it a lot easier to concentrate on the task at hand rather than getting bogged down in a lot of language details. If you’re working in Visual Studio 2003, C# is already great and will just get better with 2005; the same can’t be said for C++.

    Can C# do everything that C++/CLI can? No. But it can easily cover 80% of the code, and with many projects that figure is probably closer to 95%.

    I’m afraid that by the time Visual Studio 2005 is widely deployed, C++/CLI will mostly be at home in 1) legacy code, 2) very portable code, and 3) C++ "fanatics".

  8. Joku says:

    Well I have to pull the "old cliche", just use the language best suited to the task – and everyone Should know a few languages. Earlier it may have required plumbing but as mixed debugging between CLR languages is working quite nicely, it’s an asset to use c++/cli, c#, perl etc where they are best suited instead of just "forcing" everything to your favorite.

  9. Mike Raiford says:

    This is what I gather from this article:

    So, essentially Microsoft is dumping C++ as we know it, and moving to a CLR-based interpreted language, instead of creating native executables?

    This bothers me. For much of the same reasons I avoid Java like the plague. Every Java application I have ever used has a tremendous overhead associated with it, and seems to take literally minutes to load. I get the same "lagged" feeling with the .NET based applications. JIT compilation is just another step the target machine must go through just to get the application running. Not only that, but also, the baggage of the framework to go with it. If the program I’m creating need only be a simple console-based application, I could build it, statically linked to the run-time library, and have a relatively compact executable with no external dependencies, aside from the OS, and chances are it will build on other systems, if you’re careful about portability. Java and CLR suffer from the same downfall, megs and megs of dependencies for even the simplest of programs, a start up delay that rivals OS boot times, just for a very simple small program. I think it is very unwise to tread down the road of dumping the compactness and efficiency of C and C++, just to have this so-called "managed code"

    While the likes of Mort will welcome the change, the rest of us — the real software developers — are left out in the cold.

    These are some of the reasons why I have abandoned Visual Basic as a viable development platform for serious applications. Even though VB compiles to native code, it still, even for the simplest of programs, has to carry around a huge amount of baggage.

    Yes, yes … I know, we have 100GB harddrives and 1GB of RAM is easy to come by these days, and broadband internet connections are commonplace, but it’s no excuse for an application to carry around 5+ MB of excess baggage.

  10. Joku says:

    The few megs of baggage and 10-20% performance drop is still worth what you get in exchange. And no one is in anyway preventing doing the fully native approach either. We can quite safely assume also that the framework is loaded at all times in just few years on the win based computers, if that doesn’t cut startup delay then I’ll be also asking "what the .."

Skip to main content