Fog Creek Software
Discussion Board

what is the future of C++ programmers for windows

The Question is self desribing

Thursday, July 24, 2003

I used to be a huge fan of C++ until I discovered Delphi, C#, Java and Python...

It's not that I know all these languages and dev enviroments, but, for usual tasks (GUI apps, database apps, utilities, internet programs, etc), C++ is less productive than these languages.

I know it is more efficient, but it requires lots of training, and also, it is less productive than the languages described above.

My company does a lot of development for other companies. After taking C++ projects and finding out how hard it is to get competent C++ people, I simply refuse any C++ project.

The future is this: learn Delphi or C#.

If you choose Delphi, you have an excellent dev environment and a pretty good language, but very little chance of getting a job.

If you choose C#, you will have a big chance of getting a job, but will have to put up with a very high concentration of bugs in the .NET framework.

The .NET Framework is pleasant, tough (when it works properly / as described).

John K.
Thursday, July 24, 2003

Want to develop for Windows and only Windows, C# is an idea. Want to use the de facto COBOL of today, go Java.

Lennart Fridén
Thursday, July 24, 2003

IMHO, there seem to be two issues confounded in the answers

1. Whether C++ is a good language, C++ encourages good readable programming etc

2. Whether C++ is a good way to write Windows programs in future

You could answer either positively and the other negatively, as it's opinion

I would say you can write spaghetti in any language - question 1

As for 2, I would say yes it has a future

- Lots of apps use some legacy code in C or C++
- Lots of apps use some cross platform engine in C or C++
- Lots of apps need performance, and some truly compiled language fits
- Lots of developers like to hedge their bets for stuff like the above, jumping into .net or VB, often doesn't
- Some developers (me included) don't want to go Delphi because of some of the above, or memories of Borland radically changing the syntax of their Pascal variant (remember Turbo Pascal) in the past breaking existing programs

But, the other issue, is many business applications, above might not apply.

Before VB, business apps for Windows might have been written C style using the SDK.  Now many of these would be easier done in Java or VB or Delphi.  .net or other innovations are no different, IMHO, they make provide an alternative development route for certain classes of applications

S. Tanna
Thursday, July 24, 2003

For me the issue isn't language it is what libraries to use. MFC doesn't appear to be a priority for MS any more, WTL isn't supported, Qt is nice but proprietary and relatively expensive, WxWindows is stuck in the dark ages.

Where is the modern template/stl based windowing framework for C++ programmers?

Tony E
Thursday, July 24, 2003

My gut reaction:  The future of the language isn't good unless you're working with metal.  As soon as .NET achieves a strong foothold on the desktop (75%+) there won't be a reason to use C++ for anything anymore.  As for the programmers?  To avoid becoming tomorrow's COBOL programmers, switch to .NET or Java now. 

Thursday, July 24, 2003

I second some of John K's thoughts. Althought C++ is just about the only way to package a fast tight sexy single executable retailware or shareware, most of us don't spend day to day writing retailware and shareware. And it's terribly worrisome that someone isn't willing to learn and retain enough C++ (or worst .. can't even be found in the first place) to maintain and upgrade what the original guru has written.

In that case, the best thing to do is to restrict C++ to small DLLs that do what they do, because it's really necessary. Large complex data structures that needs to be highly efficient, sorts, dimensions, may justify it because  you want to speed things up by an order or two, but if you can help it keep it scripting based.

Li-fan Chen
Thursday, July 24, 2003

C++ will continue to be useful when writing programs where efficiency, size and speed are critical.  That's a pretty small subset of programs being written today.

Thursday, July 24, 2003

I am most certain a very similar discussion took place circa 1995 when Java was becomming popular. 

I think the future looks bright.

Thursday, July 24, 2003

How interesting, a lot of the arguments for C++ over C# remind me of the C versus C++ debate of yesteryear...

Thursday, July 24, 2003

JbR.. the only difference with the older discussion is that for one the C++ compilers of today are probably more efficient (and have more room for optimization thanks to today's processors) than the c compilers of yesterday. So the discussion might as well be C verses C#... and the difference with Java of yesterday and C# of today is that C# and the VM community are standing on the shoulders of giants. Everyone seems to know how to write a fast VM-based environment now, thanks too all the optimization research in the Java era. So the speed difference between C and primal Java is very different from the speed difference between heavy C++ and efficient C#.

Li-fan Chen
Thursday, July 24, 2003

ABout the only thing that's still true is that a better programmer can make the difference between a fast c/java/c# program and a broken one.

Li-fan Chen
Thursday, July 24, 2003

Gradual move to C#.

Thursday, July 24, 2003

"C++ will continue to be useful when writing programs where efficiency, size and speed are critical.  That's a pretty small subset of programs being written today."

Hmm, maybe I'm unique, but those things have always been very important in all the products I've worked on.

Thursday, July 24, 2003

I've been looking at "C++" job ads for the last few months; a large majority of them want C++ *and* several years of experience in some of the following { VB; .NET; Java; unix, embedded, oracle or sybase (not MS SQL), industry-specific (3D/games, financial, artificial vision) }, which has limited the number of ads to which I have been able to apply.

I'm surprised that the two of you found it hard to get competent C++ people ... I have seen so few ads and so few responses to my applications that I formed the impression that we are two-a-penny, with any vacancies easily filled by word-of-mouth ... maybe this is explained by the fact that you've stopped looking. :-)

Christopher Wells
Thursday, July 24, 2003

I think .Net is more of an alternative to VB, Delphi, Java, ASP, etc. rather than C++. 

There have been alternatives to C++ available for years with at least some of the comparative advantages versus disadvantages of .Net but C++ is still alive and kicking.  Microsoft did a pretty decent job with interoperability between .Net and C-style DLL exports and COM so there is no compelling reason to write low level stuff using .Net that might be better suited to C++ or to port existing code over.  If the traditional VB or Delphi programmers move over to C#, it might even bump up the usage of C++ because they'll be a little more comfortable with the syntax and thus more willing to drop down to the lower level. 

Thursday, July 24, 2003

I've noticed that most job ads that match "C++" aren't really asking for a programmer to come on board and write in C++. They're really looking for a person to do Java or C# programming, but C++ gets lumped in there with all those other things that such a person may have experience with. To the ad writers' credit, the laundry list of languages and tools get them more search hits, however misleading and disappointing the attention may be.

Sadly, though I have heard it described in legend, I have never seen a project moving toward C++ from another language. Most jobs asking for C++ and Java skills are migrating a rusting C++ application over to Java.

Steven E. Harris
Thursday, July 24, 2003

I'm currently writing a state-of-the-art chess program in C#, something that really requires speed as it's trying to generate and evaluate 800K nodes a second.

Measuring its performance, the nodes-per-second come to about 85% of the highly-tuned C++ equivalent, and that's before doing any hardcore C# hand-tuning. IMHO, as the compilers and CLR evolve, the speed advantage of C/C++ will simply disappear for all but the most extreme situations (real-time, etc).

For those of you who want real performance numbers for the CLR, here's an interesting MSDN article that I recommend highly:



Mark Pearce
Thursday, July 24, 2003


The MSDN article seems to be interesting. 

However, I have concerns about some of the apps written in C# that I have downloaded to play with -- notabley SharpDevelop (  This program is a replacement IDE written in C#.  Running it and opening a reasonably sized project pushing memory usage up to ~200 MB.  Open a code editing window and the processor usage goes up to 15-20% even when you are doing nothing.

Should we expect this as normal with managed applications until developers grow used to writing them and their quirks?

Funky Man
Thursday, July 24, 2003

Maybe the question should be, what can we do to accelerate C++'s well deserved demise?

For how an OO extension to C SHOULD be done, look at Objective C.

Jim Rankin
Thursday, July 24, 2003

This debate has gone on for _years_, and it's fascinating how many people were _sure_ that Visual Basic (which hilariously uses a similar "JIT" runtime engine) was the next great thing: Who would develop in C++ when they could have the awesome RAD power of Visual Basic (and from every corner you could hear defensive VB programmres proclaiming the death of C/C++). Then came Java, and proclamations that the cross-platform capabilities, coupled with JIT that could "optimize" and "reoptimize" would yield tremendous speed improvements (through some abstract and hard to quantify amazing improvements that the "compiler" would produce, ignoring the fact that the language doesn't have performance primitives to "tune it" as people often claim that they can). Here we are today and virtually every single shrink-wrapped application you can buy is written in C++ (>98% I'd say). Prophecy that this will undergo some drastic change just boggles the mind and SCREAMS of people who forget the past and are doomed to repeat it. Especially telling is the number of people who laughed off Java, yet now they are die-hard C# advocates preaching that it's the greatest performance improvement ever....the hilarious contradictions. I love C# because it's a great language (a marriage of C++ and Delphi Object Pascal) and the .NET framework is a tremendous set of existing code to leverage, but the love-in for the virtual machine just reeks of ridiculousness--Have people not learned from the decade long Java experiment? How many apps do you run nowadays that are Java? Did you advocate Java, which also offers cross-platform abilities, as hard as you now preach the .NET mantra?

I have absolutely no doubt that for in-house applications where there are few users and a limited need for competitive performance, RAD tools, such as Delphi, Visual Basic, and C#, will dominate, and there is absolutely no doubt that .NET is a massive improvement over Visual Basic, just as it's a massive improvement over ASP. However claims of great strides in productivity of C# over C++ for _large_ scale projects (i.e. projects where the "time to throw a control on a form and press F5" is a rather small factor--the RADishness tends to even out over the long run if your "leaky abstraction" costs you tremendous amounts of time trying to plug he holes, such is the case with most high level languages). are unfounded. Even more unfounded are absolutely _ludicrous_, and ignoring of the past, claims that a virtual machine system, such as C# or Java, will somehow evolve into an amazing performance paradigm reeks of ridiculous optimism. Now what C# does offer, mostly using the pre-existing COM IOP, is an ability to use high level languages where appropriate, and low level languages where appropriate (which is how we get examples like "Quake II in .NET!", which is more like "C# calling out to native code"). That is where the intelligent users use the tools appropriately, though I have no doubt that large scale projects like shrink-wrapped retail software, games, and virtually all open-source projects, will continue to be developed in C/C++ for at least 15 more years.

Dennis Forbes
Thursday, July 24, 2003

Dennis, you say "look at history," yet you ignore history yourself.  History has shown us that we are willing to give up efficiency for languages that make it easier to design large systems, and improve productivity.  How do you think we got to the point of using C++ in the first place?  Now whether you think C# provides these improvements over C++ is a side question.

I have no doubt that within a few years, large amounts of desktop software will be written in C#.  It overcomes many of the problems of java (UI look and feel, for example).  In addition, from preliminary reports, the overhead does not seem to be as significant as it was with java.  This will be especially true when the CLR is used more ubiquitously in Windows, so you won't have to pay the large overhead of loading a VM when your program starts.

You discount the idea of VMs providing superiour performance based solely on Java's example.  Just because Java failed in this regard, doesn't mean it is impossible.  See this article about HP's Dynamo:

While not the same as a VM, this shows that dynamic translation can offer superior performance to simply running a native binary.  Whether the CLR can deliver on performance like this, we will just have to wait and see.

All that said, C++ will be around for a long time to come.  If for nothing else, it will continue to be used in speed critical sections of code, where the developer feels he/she needs full control

Mike McNertney
Thursday, July 24, 2003

Apologies for the numerous wording errors and mistypes in my last email-An unfortunate side effect of spitting out an email while a meeting deadline looms.

As a standard disclaimer, please don't presume that I'm anti-.NET...I am not definitely pro-.NET (indeed I had an article in the July issue of MSDN relating to using C#). .NET is a tremendous tool and I am definitely a fan and am utilizing it into many of my projects. It is a great stride forward in many areas.

What I am not a fan of, though, is the tendency for people to portray virutal machines as something new (they have been around for decades. This whole concept was well hashed over during the early days of C. Actually before that), always propping their conclusions upon extremely optimistic futuristic suppositions - IF we develop a whole new breed of super JIT compilers, soon VM software can be faster than machine code! Again I'll point to Java - There have been billions of dollars put into it by a lot of the industries biggest and most skilled heavyweights, and where are we today? Java is the sort of solution you use where you have such an excess of machine power that it just doesn't matter, or where you're choosing some absurdly narrow-scoped trivial demonstration as a benchmark. Despite all of the anecdotal evidence claiming C# exemplary performance, where are the SPEC numbers to back it up? Microsoft, of course, has never come out with them because they have never pushed managed code as some paradise of performance where you can have your cake and eat it too: There are performance costs to things like garbage collection and security abstraction from the hardware that cannot be circumvented. Well they have pushed it as a performance advantage over some of the interpreted solutions like the WSH, and it most certainly is, but that is a no brainer.

"History has shown us that we are willing to give up efficiency for languages that make it easier to design large systems, and improve productivity."

Agreed, however that largely applies to in-house corporate applications, not to commercial applications. Given two commecial applications, one where the developers made it easy for themselves (theoretically) the one time they wrote it, yet at a performance cost for the millions who run it, or another that is extremely efficient but they had to have a tighter development process, which do you think will be the commercial winner? Obviously I'm ignoring the fact that some tools can scale to a greater degree, allowing for more features for instance, but I think we already have that sort of scalability with black-box technologies like COM.

Dennis Forbes
Thursday, July 24, 2003

What do C++ programmers do to ease the unnecessarily troublesome part of C++? Are there libraries that go beyond the call of duty to do what the lazy programmers have no time to deal with besides Rogue Wave? Any of this LGPL or BSD-licensed?

Li-fan Chen
Thursday, July 24, 2003

To respond to Funky's post, determining memory usage in a .NET app is tricky.  .NET's strategy is to keep allocating memory until it runs out, then do a garbage collection cycle.  If you have a lot of memory, it will look like the app is a hog.

The framework will do GC cycles like crazy rather than page.  It's more memory efficient than it appears.

Bill Carlson
Thursday, July 24, 2003


I was using the .Net Memory Profiler (
to get this number.  I had it setup to count only live instances.  I agree that the number in TaskManager should never be used for any app.

Funky Man
Thursday, July 24, 2003

If 98% of "real" apps are written in C++, then why does it seem that almost all jobs advertising C++ tack it on after Java, .NET or all these new-fangled technologies?

As a C++ developer I would really like to know.  I guess because most development is not shrink wrap development, but internal development?

Or is there some other factor that makes C++ less visible than all these new technologies, even though supposedly it is much more widely used thana ny technologies.

Thursday, July 24, 2003

Current C++ development is very different now than it was 5 or 10 years ago.  And to me at least, it beats the pants off C#, Java, etc.  With UI code being the possible exception.

Where else can you find the full expressive power of modern C++ templates, the combination of fast and "worry only when you need to" memory management with RAII, the efficiency of fewer layers between you and the metal without losing generality and abstraction, etc...

Oh, and did I mention it's portable?

Michael Kale
Thursday, July 24, 2003

Hi Dennis,

>> ... (which hilariously uses a similar "JIT" runtime engine) was the next great thing... <<

With VB.Classic, you can either use the interpreter - most definitely not a JIT compiler - or you can compile to native code - which incidentally uses the standard VC++ compiler.

>> Despite all of the anecdotal evidence claiming C# exemplary performance, where are the SPEC numbers to back it up? <<

The MSDN article I mentioned above has some real hard-core numbers that you can examine and test for yourself. In addition, I spend more time profiling and tuning my chess program than writing the code, so I'm pretty confident now that it's running at approximately 85% of its C++ equivalent.


Author of "Comprehensive VB .NET Debugging"

Mark Pearce
Thursday, July 24, 2003

Mark, how are you getting your 85% figure?  Did you write the exact equivalent program in C++ and spend a decent amount of time optimizing it?  If not, what are you comparing your program's speed with to get the 85% figure?

As the author of a state of the art chess program myself, I am a little surprised at your claim.  But maybe VM technology is better than I thought?


Peter McKenzie
Thursday, July 24, 2003

Andy - because the advertisers want you to think that you will be playing with sexy" new technologies. They could write the advert as "Do the same thing as you are doing now", but it wouldn't attract the same response.

Friday, July 25, 2003

I don't know, I think C++ developers like C++.  Advertising for .NET and all these new technologies isn't going to attract C++ developers.  I think the thing is that C++ really isn't a skill any more... e.g. MFC and COM are the skills people are looking for.  It's better to have some knowledge of these proprietary technologies and a shoddy knowledge of C++, rather than the other way around, apparently.

It seems like all the good C++ developers are doing their own thing in their own small companies, or doing open source.

Friday, July 25, 2003

Hi Peter,

As a model, I'm using Robert Hyatt's Crafty program, for which full source is available. It's true that the algorithms I'm using aren't always identical to those in Crafty, so it's not entirely comparing apples with apples. For instance, I'm doing quite a lot of work on singular extensions.

But in general, doing a direct node count comparison, Crystal (my program) is running at about 85% of Crafty's speed. The exception is in certain endgames, where Crystal is much slower, for reasons I don't yet understand.

The CLR uses a JIT (just-in-time) compiler to compile each method in CIL into native x86 code and then run the native code. Although there's a small delay for JIT compilation of each method as it is first called, every method called runs pure native code with no interpretive overhead.

As Jan Gray states, the list of optimisations that the JIT compiler performs is impressive:

Constant folding
Constant and copy propagation
Common subexpression elimination
Code motion of loop invariants
Dead store and dead code elimination
Register allocation
Method inlining
Loop unrolling (small loops with small bodies)

Even for garbage collection, the amortised cost of creating and later automatically reclaiming an object is sufficiently low that you can create many tens of millions of small objects per second.


Author of "Comprehensive VB .NET Debugging"

Mark Pearce
Saturday, July 26, 2003

I have no Idea about the future of c++, I'm learning it now and have a slight knack for it over java. What concerns me is rather or not my time is wasted on c++, when Java or C# is going to be the future. I agree with people when the y say Java's slow because it is. C++ seems to be more extensive then anything else you can work with and this is why it is difficult, but it is also so much faster right now, I like what c# is supposed to be the code is closer to c++ to me anyway than Java is but my question is will I get a job progrraming in any language. All this is confusing as hell, and picking a language means an investment in time for me. Foul if all the time is wasted on something obsolete or not in heavy usage. I like c++ though and what you can do in c++ blows the pants off of VB in any respect, If you're in a hurrry program in VB if you want power use C++, and DAMN! theres a language called D now FUCK!

Tuesday, April 20, 2004

*  Recent Topics

*  Fog Creek Home