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

• Anonymous
  May 28, 2004
  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.

• Anonymous
  May 28, 2004
  The comment has been removed

• Anonymous
  May 28, 2004
  Here's a suggestion - before inventing a new C++ language variant, how about making Visual C++ compliant with existing standards first, namely C99? Grumble...

• Anonymous
  May 28, 2004
  Will there be a public beta for this? Or do I have to wait until 2005 :( I would guess so.

• Anonymous
  May 28, 2004
  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...
  
  WM_MY0.02$
  thomas woelfer

• Anonymous
  May 30, 2004
  The comment has been removed

• Anonymous
  June 01, 2004
  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".

• Anonymous
  June 01, 2004
  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.

• Anonymous
  June 01, 2004
  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.

• Anonymous
  June 02, 2004
  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 .."

• Anonymous
  June 16, 2009
  PingBack from http://workfromhomecareer.info/story.php?id=15935

• Anonymous
  June 17, 2009
  PingBack from http://patioumbrellasource.info/story.php?id=2495