That's exactly why I like C# so much. It's just too bad that we are restricted to one single platform by using it :(

C++ is difficult and for experienced programmers, experience at least with C. You can do whatever you want fast. But it is not for everyone.

Daniel: You can code cross platform with C#, Mono has come on leaps and bounds. You do have to put the extra effort of making sure your code is fully compatible with Mono and that you don’t use anything windows specific. You don't get anything for free ;)

Jeff: I whole-heartedly agree! C++ is a great language for hardware interaction or even for making a component that has a need for the most performance possible, but its power and flexibility means you have to take more control and responsibility over everything. More recent high level languages like C# take some of that power and flexibility away, but with less under your responsibility to directly control your productivity is greatly increased and the language/framework can protect you from many common mistakes.

Strangely, in my feedreader (Newshutch) the whole article references C and not C++...

There is another (than MS) C# compiler in existence:

http://www.mono-project.com/CSharp_Compiler

But alas, whatever the language, there will always be cases of "(accidental) use of the ordnance to hurt yourself".
Some languages protect you more, many protect you less, but incorrect code is always incorrect code.

there's a new language out there released just a couple of weeks ago called "D". It offers performance and flexibility of C++ and high level features like garbage collector. Syntax is very similar to java and c#.

http://en.wikipedia.org/wiki/D_programming_language

So C++ was a step in the wrong direction if you want a general-purpose programming language. For most tasks its’ complexity is harmful.

Still, new mainstream-languages like Java and C# adopt the C and C++’ syntax, the type system, and control structures. Maybe it is time to realize that all languages that stems from C are broken?

hotdogs: D-1.0 was released couple of weeks ago. D itself lives for dozens of weeks now.

wow, way to go spreading FUD.

"it's dangerous"? a programming language isn't dangerous. an uneducated programmer is dangerous. if you can't program well in something, either better your skills or stick to something you know.

by the way, is something just really screwed up with your CAPTCHA system, or do i just keep getting "orange"?

To me, C++ is a better choice for most embedded software, excluding UIs. Java and C# are preferable as you get closer to the user and performance becomes less of an issue. At the lower layers, though, there will always be a need for a C++ type language. These components are small in number, but very important still.

I work in the embedded (Linux) world, and the real problem I see is that there is still too much use of plain C: C++ would be a step up, but it hasn't taken off. It will be interesting to see if Mono fares any better.

C and C++ will always be around, just like cement will be for construction.

The difference is these days we don't need to worry about the cement and we can just get on with building the house.

* DISCLAIMER - Cement may not always be around

It is only dangerous for incompetent programmers, real C++ programmers know there standard library and use reference counting pointers where needed. Having said that, you don't seem to give any points yourself as to why C++ is dangerous, you probably don't even know why Bjarne Stroustrup mentions all these points.

I would like to know what you are trying to achieve with spreading this kind of FUD and miss information? Did you ever use C++? Are you a D-programming language zealot that is insecure about his programming language or something? Or are you just uneducated?

Spoken like a true VB programmer. C++ is a very useful, powerful, and relevant language. No need to bash it because you don't use it.

If you take the shooting analogy further, you would blow the whole guy away if you do it in C#. If a language is deemed "easier" it automatically requires less brains to do the job.

There's nothing wrong with cement (concrete). We've been using it for thousands of years, and it should be good enough for a thousand more. Now just overlook the way it fails in tension, leading to problems with earthquakes and hurricanes, the way it takes lots of hand-built forms and hand-wired rebar, and the terrible insulation properties.

On the other hand, you could deliver a bunch of lightweight panels of carbon fiber/epoxy honeycomb with any old pickup truck, and glue them together at the job site. Maybe it's time for a carbon-fiber programming language, too.

Bjarne's response sounds very sensical. I do not see anything defensive about it. We should be using a wide variety of languages and some, like C++, should exist that aren't dumbed down for casual programmers. And yes, there are still far too many idiot programmers employed these days...even after the tech crash.

The C language was wrongly misused for business applications. C was handy because of the notion of having one source that could be compiled on multiple target machines, yet have near Assembler speed.

Delphi (Object Pascal) became such a hit, and many, many commercial apps are written in it, because it allowed you to do business development quickly with a highly powerful language that could do most of what C or C++ could do, and usually match it's speed. It has very good garbage collection, and it's clear how the Borland engineers who left to go to MS have influenced the MS products we have today.

Borland's internal reorganization aside, Delphi remains the best Win32 dev tool in existence, and a decent .NET dev platform. One which even allows Win32 Delphi apps to be recompiled for .NET, preserving the developer's code base. Something MS did not make available for all the VB and C++ apps that needed to be converted to .NET.

C++ is here to stay, at least for a while; 10 or 15 years at least. There's just too much code already written in C++, especially libraries. Even if we are able to use all those libraries in all other languages, someone has to maintain the libraries.

Forget "D", I really like the "E" programming language:
http://en.wikipedia.org/wiki/E_programming_language

"E is an object-oriented programming language for secure distributed computing, created by Mark S. Miller and others at Electric Communities in 1997. A concurrency model based on event loops and promises ensures that deadlock can never occur.

"The entire language is designed with secure computing in mind; this is accomplished chiefly by strict adherence to the object-oriented computing model, which in its pure form has properties that support secure computing. The E language and its standard library employ a capability-based design philosophy throughout in order to help programmers build secure software and to enable software components to co-operate even if they don't fully trust each other. In E, object references serve as capabilities, hence capabilities add no computational or conceptual overhead costs. ...

"In E, all values are objects and computation is performed by sending messages to objects. Each object belongs to a vat (analogous to a process). Each vat has a single thread of execution, a stack frame, and an event queue. Distributed programming is just a matter of sending messages to remote objects (objects in other vats). ...

"E has two ways of sending messages: the immediate call and the eventual send. An immediate call is just like a typical function or method call in a non-concurrent language: the sender waits until the receiver finishes and returns a value. An eventual send sends the message while producing a placeholder for the result called a promise. The sender proceeds immediately with the promise. Later, when the receiver finishes and yields a result, the promise resolves to the result. Since only eventual sends are allowed when communicating with remote objects, deadlocks cannot happen. In distributed systems, the promise mechanism also minimizes delays caused by network latency."

Reading the responces is interesting. I may be a hobbyist programmer but I've never understood why I need to consern myself with the dirt and grime of the lower workings just to write an application. As has been mentioned, it's great for low level stuff, it's great for cement, but it really isn't friendly for high level stuff. I read dozens of people saying that if you can't program well in C++ then get better, or you should give up. But tbh, I don't want to need to program well in C++. I can, but for a Win32 application why should I need to worry about the ton of stuff C++ forces me to worry about just to get basic stability? Why can't I concern myself more with ironing out the bugs in my application and making the code I've written to do what I want actualy does what I want rather than worrying about the lower levels? But I'm sure people will still cling to using C++ to program websites.

I'm never going to use E as long as examples show people protecting a 'return' statement with an 'else.' That's why I don't use C anymore--the same idiotic motif shows up in K&R. And those guys were supposed to be good programmers. Gaaah!

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."

C# makes it harder still, but when you do, you don't know where your hit.

I don't think it is right to just say that "C++ is fast" without qualifying such a statement. C++ allows you to optimize code at a micro level more than any other language that also has high-level features.

That said, most optimization problems occur at an algorithmic level. In those cases, I find that refactoring C++ code is typically far too difficult. It may merely be the lingering presence of header files, but C++ just lacks crucial malleability. Changing anything at all becomes a major chore.

C++ is the cornerstone of software engineering. Yet, as mentioned before it is a full spectrum language, which can be used either for low level or high level applications.
It is completely natural that other languages have been grown and evolved towards specific software types. And they probably do the job easier than C++ (trying to engineer a dynamic website in C++ would be a real fuss now)
Yet, one great thing about C++ is that its blazing FAST! And as it is really difficult to use and code with ,it may not be used for enterpise related applications- as they don't have really great speed requirements (most of the time at least). But is used very much , and probably will keep up like this, in the research and academic facilities where speed does matter. I can't imagine programming a simulation enviroment in java, as a run circle would take up as much as 20 times more than if it was created in C++.

As for the "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." I certainly disagree. C++ is an Object Oriented Language . Object Oriented Programing enables the programmers to do really careful code planning, memory management. Whatsmore every component/module can be tested/debugged separately and in a much easier way as OOP provides with the best support for unit testing.
This way totally efficient and fast applications can be programed, in cases where other languages would reach their limits (I cannot imagine how I could code an emulation enviroment which takes up 2GB of dynamic data into the RAM and perform constant and painful processing over them for more than a million emulation queries).

I don't believe that C++ has somewhat lost its value, I just believe that the new wave of software engineers are not up to programing the "hard way". Of course they are not oblidged to and it is best for everyone that they chose the best programing language to them (in means of stability, efficiency and scalability). C++ will definately stay around for 10 to 15 years, but it will not be massively used.

C++ is great for what it's great for, systems programming. What people often fail to realize is that no language is perfect for every task. When productivity, readability, and maintainability are your main concerns you're much better off with Python (had to get a plug in). But you'd never use Python for a device driver, and you shouldn't use C++ for a database program (although it's way better for that than C).

I think some people still use C++ for commercial development as its harder to reverse engineer than the newer languages (Java, C#, Python) which really matters to some people.

I recently benchmarked some protocol decoding (proprietary protocol) in Python, Java and C++. C++ was 13x faster than Java (based on the implementation, C would be similar). And C++ was 150x faster than Pure python. Considering how much time my server applications spends decoding 'messages', these performance numbers cannot be ignore.

Note: I'm not an expert Java developer, I had experts tune the Java test case.

Certain languages/environments are more dangerous than others. Look at all the buffer exploits for C code, or all of the SQL Injection problems with ASP (classic) or PHP. (Or the performance problems with Java strings in early versions of Java.) While C++ is definately safer than C, it's still more dangerous than C#, Java, or Delphi.

C++ certainly has its faults, but if you can stay out of the worse parts of the neighborhood and use decent quality practices, you can write some very good software in it. I've never bought into the "era of abundance" paradigm, since it encourages sloppy practice and general cycle-wasting.

Wasted cycles cost money, in case you'd forgotten that. It's the "I'm going to drive an SUV because it's 'safer'" argument, while blithely ignoring that the 'safety' costs minimally twice as much to maintain as with any other vehicle; a well-built, safety-conscious smaller vehicle would be perfectly viable--just so long as you don't have the larger gas-guzzlers careering all over the interstate.

Languages that get more done in fewer cycles cost less to run at the plug. Arguments over maintainability will seesaw back and forth over the decades, and that's a separate set of costs, anyway. (SUVs cost more to repair, too, if you want the analogy.)

This is not to say that there isn't some other middle ground. C# is very well thought-out, and very easy to learn for a C++ programmer. (Maybe even for Java programmers, but I don't see a lot of them volunteering.) Not sure about the economics of C# yet, but I'm thinking about it.

"But we've long since left that behind; we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop. "

Ok - that bit *really* worries me! Why not just advocate badly written code, hell the machine can cope!

But this point:
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous."
is one very well made! I am fed up of dealing with "developers" who have learnt a smattering of php/python or heaven forbid Ruby on Rails it is a real big problem these days - too many hobbyists!

I've not used C# so I really cant comment on it. I do use Java quite a lot and find it does the job well enough...but C++ is my langauge of choice. A well-educated C++ programmer has nothing to fear!

I've always sort of considered C++ the library language. The only way to really glue a language to an OS is to use C++ to create the libraries and such. I mean, look at anything ported from Linux to Windows: the only way they work is through DLLs (or using CygWin or a few other ideas that are less easy for the novice), which are in turn coded through C++. The majority of the DLLs are careful ports of C++ files. C++ is such an integral part of the low-language structure of most OSes that you really can't side-step its use. I mean, can you imagine trying to do anything serious on Linux without gcc?

My frustration is that there are still a number of game programming libraries that require C++, because that's one of the places where speed is still VERY much a factor. You just don't have the same superior output from most other languages as you get with C++... and that's just kinda sad.

There will always be projects where you need as much speed as possible, partly because what you undertake gets more ambitious as machines get faster.

Also, you'll often see parallelization cited as the cure for Moore's Law coming to an end, or at least having reached a flat spot. Well, not all algorithms are parallelizable, and when they are, it's frequently hard to do so, and you lose total CPU efficiency, putting pressure back onto optimizing the heck out of everything. So, the need for speed will never go away, and one might even project from this that the use of C++ will grow!

As for the idea that C/C++ are no longer relevant, what do you think the application you are reading this with is written in? You may have some new-fangled child-safety language working on the server side, and JavaScript on the client end, but C/C++ is there everywhere. Your browser is written in C++, running on an operating system with C at the core, and a good chunk of websites are served with Apache running on Linux.

Take the cement/concrete analogy and run with it a bit. As a new building using ready made carbon fiber panels (mentioned above) rests on a foundation of concrete, so too does your Web application written in [insert fashionable language] rest on a foundation of C.

Maybe we don't need more experts to learn to program close to the hardware. We need just enough to get the hard 'dirty' work done so the rest can do their work. There will always be a need for systems-level programming, the question is how much.

It's stupid to make pronouncements as if there is one true language for everything. I would never build a web site in C++. I would never build a GUI in PHP. This is a topic as ridiculous as Mac vs. Windows. Use the right tool for the job or go home.

I just want to correct a couple things:

1) Delphi/Object Pascal doesn't have garbage collection, except possibly in the .NET version. When the language itself is compiled to native code, you do manual memory management. It's still far easier than C++, though I sometimes wish for stack-allocated class instances.
2) C++ blows for kernel programming. See http://www.osdever.net/tutorials/pdf/cpp_kernel.pdf and http://www.osdev.org/wiki/C_PlusPlus. Notice the sheer quantity of runtime work you have to do before actually compiling a kernel with full C++ features. I write a kernel in Object Pascal, and I had to do only a small fraction of that to make a working RTL under the Free Pascal Compiler that would run on bare metal.

C++ is really a language for driver programming or low-level applications programming. Don't try to take it lower or higher than those.

Many people seem to think C++'s niche is 'systems programming' and 'Devices drivers'. That may be true for user-mode level programming. However, C++ has some issues with programing anything in kernel mode. Check out this blog by Adi Oltean, and the white paper it references:

http://blogs.msdn.com/adioltean/archive/2005/04/24/411356.aspx

whitepaper:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

• The use of the C++ compiler as a “super-C” is typically expected to work, but such use of the compiler is at the developer’s own risk.

• It is currently impractical to identify problematic C++ constructs mechanically, so developers must carefully analyze the compiler output to ensure that the generated code is suitable for kernel mode.

• Before committing to the use of C++, you should carefully assess whether it will work for you. In particular, you should test C++ constructs early in the development process, to ensure that the constructs do not cause the problems described in this paper or otherwise violate the principles of kernel-mode driver writing.

• Some of the problems discussed in this paper might not become apparent until near the end of development, and that solving them might require code to be completely rewritten.

• Several of the most insidious problems are extremely difficult to reproduce on demand while testing the driver, so a driver with an inherent unreliability might appear to run for extended periods with no problems and fail at random times. This reinforces the need for careful analysis.

The bullet points in my previous post are quoted from the whitepaper. I should have been more careful to make that apparent.

Funny to see people still using VB as a whipping boy when there hasn't been a new release in over 8 years!

C++ is and will continue to be relevant because it has no real competition in its problem space today. That doesn't say anything about its quality one way or another.

Other tools encroach on the fringes a bit, and every day we seem to see new introductions with potential. They just aren't there yet and sometimes that's simply a question of momentum.

I see C++ as an incredibly unproductive language choice, but when the alternative is simple C or even assembly level coding it is just too hard to argue with. For low-level work it continues to hold a significant advantage.

That doesn't mean a contender based on Algol couldn't invade and compete in this space. Delphi has done well in making inroads partly into C++'s domain and FreePascal has had some benefit in tearing down the wall of propriety around Delphi. Other languages descended through Pascal haven't achieved so much, mostly because of excess academic baggage along with relative obscurity and rapid churn and divergence.

Stability is one of the best things C++ has going for it. Change has been evolutionary at a pace the industry has been able to absorb and implementations aren't so divergent as to cause unnecessary headaches.

"That's exactly why I like C# so much. It's just too bad that we are restricted to one single platform by using it :("

My friend, you CAN run C#.NET programs on Linux/Mac/Solaris machines.

http://www.mono-project.com/Main_Page for more information.

Article made the front page on Digg.

"too many software developers are undereducated and undertrained."

What a lame statement. Same could be said for people that like to code in C/C++ instead of ASM. Languages do not evolve to meet the needs of the lesser educated, how can such a smart guy make such dumb statement.

Portuguese translation of this article - summary.

C++ is OO assembly language. 5 years ago for the majority of apps there was no call for an __asm, now the same might be said for __c++ (sic).

Jeff Atwood wrote "... we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop."

Even if it was true that "We have more computer power ... on the desktop" then we might still have a scarcity of computer power on servers, on mobile phones, on sensors, on autos ...

My company codes in c++, c, php and Eiffel to name a few. I have to say, Eiffel is seriously amazing. Check out the wikipedia link. Eiffel has Garbage collection, pure object orientation, it's elegant and NOT based on C. Oh, and it's open source. Check it out here actually rates just under C++ in speed, http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=se&lang2=gpp

Stroustrup's books have always been the only ones I could read through and even enjoy. C++ is the only language I ever relished learning and playing around with. A few years programming with PHP, Java, ASP and the like, and I don't even want to be a programmer anymore.

I loved the prevalence of grammatical and spelling errors in a lot of the responses, especially the ones arguing that C++ programmers just need to be better, more educated programmers. To be a good programmer you need to be aware of what you are writing in all languages. If you can't be bothered to take the time and have a good awareness of your grammar in quick responses to articles, how you can expect to have a good awareness of your code?

But does anybody agree with me that these days we have a lot of "programmers" who don't even know what a bit is? I personally know people who, when implementing some simple network protocol, used string and changed separate characters in it just to change packet's options. They didn't know how to do that on integer field! We're getting dumber programmers who don't even know how to read hex! And they call themselves "programmers", ha ha.

There are only two things wrong with C++: The initial concept and the implementation. (Bertrand Meyer)

http://www.sysprog.net/quotec.html

And I would say every subsequent attempt to "fix" the original in the various "ISO C++" standards. C/C++ have set back software engineering decades IMO.

I am waiting for the language Z#.

I figure by then the computers will be programming us.

"I'm afraid I can't do that Hal."

@Peter

We're developers, not English Teachers... Wut a dumm risponse.

Sounds like someone who writes only in VB, and not well. You obviously can't write a lick of real code if you spent the time to worry about the grammar.

I think Bjarne makes a strong point about the undereducation of a lot of programmers. If I'm asked to write a web app I'm going to do it in C#, Ruby, or some other such language, no question about it.

However, if I were asked to do it in C++ I wouldn't miss a beat. This is because I understand memory issues, et al. How many of the *younger* web developers running around really understand it beyond the few articles that they've read?

The other point I want to make has to do with what Joel Spolsky calls "Leaky Abstractions". All abstractions leak to some extent. The ones that can truly understand the lower level abstractions can cope with them better than the ones who can't.

C++ may not be the best tool for everything, but knowing it sure as hell doesn't detract from your skills as a Python programmer.

"But when was the last time you used C++ to write a line of business app or website?"

When said app/website needed something computationally intensive done in a short amount of time. There's a reason why all successful languages today provide facilities for calling into C/C++ (this includes Java).

I don't believe that we have more computing power than we know what to do with on the desktop. In fact, I think this attitude is ruining the desktop experience. I have a brand-new MacBook Pro; pretty fast, right? Wrong. It feels not a bit faster than my 1 GHz Athlon running GNOME -- no slimline itself -- because of the inefficient software. When IRC clients use 200MB of core and keychain daemons use 100, even while very few desktops have more than 1 GB of ram, we need to reconsider this gung-ho disregard for program efficiency. I agree that high-level languages are wonderful and worthwhile, but we still need to pay attention to our programs' resource consumption for a few years yet.

The comment about speed is not surprising, but nonetheless incorrect. First, there are areas where speed is more of a consideration now than it was five or ten years ago. Second, software is becoming bloatware. Take Vista as an example. I would argue that computers are becoming slower for everyday tasks, because apps these days tend to use a LOT of resources. Build more highways, you get more cars. Build faster computers, you get more resource-hungry programs.

It is true that Windows 98 and the apps we were running at that time will run faster on our current hardware. I don't think we'll see most games being written in Python anytime soon.

The first paragraph from the quote is probably the most important:

"However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts."

From first-hand experience, I know that many Computer Science majors that are graduating today have little to no C/C++ experience and have minimal experience with assembly. Most programming is done with interpreted languages (Java, Perl, etc.). While there is nothing wrong with this, I find it disturbing that Master's students have no idea what a 'pointer' is and how to use it.

Now that I've had my rant...

C/C++ is nowhere near 'dead'. C is still the industry standard for embedded devices, probably because it is so close to assembly - if anybody has ever tried to write a networking library in C vs Java, you'll know why software engineers use C... When you're at ANY level other than the application level (aka.. system-level, kernel, firmware, drivers, etc.) you really need access to the resources and control that C and C++ give you (full blown assembly is usually over-the-top, but it happens in many critical sections).

That being said, there are a lot of applications that C++ just plain doesn't make sense for. I know that using Java for a GUI frontend is a fantastic way to do things. Or for a quick app that 'just works'. But for computationally intensive applications, C/C++ is usually the way to go (unless you're working on supercomputers - most research-grade MPI apps are just now making the transition from Fortran... no pointer-chasing!).

(Just a few of my thoughts).

Strangely enough, I've seen several arguments in favor of C++, but not one mentions video games as a major reason for keeping C++ alive. After all, video games _do_ need speed. You're not going to see Doom 4 programmed in Java, that's for sure.

It seems the main problem is that people are confusing C and C++. You can see that by the usage of the "C/C++" expression.

C and C++ are totally different programming languages.
C code is basically the worst thing one can achieve in C++.

Another problem seems to be that people think C++ is for Object-Oriented Programming. That's not the case at all, while it is possible to do so (it is also possible in C, by the way).
Support for OO in C++ is actually rather limited and its usage is discouraged in favor of Object-Based programming and templates, which are not only more efficient but also type-checked and therefore have correctness enforced by the language.

So basically, when you say "C++ is C with OO" you are two times wrong.
The key features of C++ are exceptions, deterministic resource management through RAII, overloading of value semantics, and templates.

Also, C++ is not dangerous at all. While dangerous things are indeed allowed, you have to write specific code to do so that is easily spotted. If you follow normal code guidelines, the typical problems of a C program (memory leaks, heap corruption, memory "stomping", invalid output, "crashes" far removed from the site of the error) can't happen.

C++ is dangerous in the wrong hands, all too often do i see code written to a degree of abstraction that is frightening. I think this comes from a lack of understanding of software structures and fear. This is how it usually happens. One person who seems to really understand what's going on with a project writes the initial code base and creates and interface. That person leaves the project, then others come on to the project. Rather than modifying the previously written code directly, layers of abstraction are added to avoid modfiying code that's not "understood well". This continues through several teams until you have a sort of house of cards implementation which deviates from any standard design concept. I believe alot of people use C++ because it saves time and certainly the STL is something alot of C programmer envy periodically when they really need a hashmap. Honestly though, I do quite well with C, i actually enjoy C quite a bit, I have pointers, i can't imagine needing anything else. If you're looking for an object oriented approach, i recommend you learn Ruby, it's almost purely OO. C++ does a good job implementing OO features in a compiled language but it pales in comparison to the flexibility an interpreted language can provide such as Ruby. In the end I believe it's a matter of "use what is appropriate, and annoys you less", it's somewhat of a personal choice, we should be glad we have so many choices, and that includes C++.

The fact an IRC client takes 200MB isn't because, as is the point of the argument in this post, the language it is written in doesn't allow the fine enough control to scrape every last bit of memory. You can increase/decrease performance even in higher level languages quite dramatically. Of course we shouldn't have a blatant disregard for the fact we might be playing with other apps, but neither should we be as concerned about every last byte and we can, at times, allow things like garbage collection to takes the reigns for a bit. That's the point he's making. The trouble is that many people merge the two and think they don't have to have any thoughts about performance, which is fine when they're developing it. But when users then combine this with dozens of other like-minded apps things start to get a little sluggish.
You give people an inch and they take a mile, but tbh as a developer I'm very mightly greatful for that inch.

C++ is just a mess. It tries to do too much. STL in particular is horrible.

I'm sorry but the comment "It was an appropriate solution for an era of limited computing resources. But we've long since left that behind; we live in an era of abundance." really destroys your entire argument on the subject.

If you want fast, you use C++. By saying that computers are already fast enough, you aren't answering the question but deflecting it.

I've written a ton of apps in C#. I love the ability to write something rapidly. However, I still prefer C++ because it's not so tightly bound to Windows (and don't bring up Mono) and it doesn't hold my hand quite so much. I know what I'm doing and if I don't, I deserve to have my leg blown off.

I think your post you linked to makes the point beautifully (http://www.codinghorror.com/blog/archives/000224.html). This post is not a bash of C++, it's a plea to program at the right level.

Using C++ (or even assembly) to optimize a 3D game algorithm makes sense. Using C++ to write a line of business data driven web application makes less so.

The trend is to optimize developer productivity over code performance (http://haacked.com/archive/2006/09/13/Premature_Optimization_Considered_Healthy.aspx).

Just look at widgets that run on various desktop platforms such as Vista's sidebar. These things can be written in a *shudder* SCRIPTING LANGUAGE. The sky is falling! Amazingly, my desktop and machine performs great!

C and C++ are only needed until there is an optimizing compiler that can take a high level language and make it as fast as a compiled C program. Then, who would ever use C or C++ again?

Haha, you obviously have no idea how a compiler works and what the difference is between a compiler, an intepreter, a bytecode and a JIT compiler.

Anyway as someone way above stated very clearly C will always be used for low level stuff, kernel and drivers. C and not C++ which has nothing to do with C whatsoever. Furthermore if you want speed or small code you use C, not C++ and all the mess it generates with classes and stuff.

FYI -- there is now post-tension concrete that actually makes concrete harder because it is compacted. also, there are different grades of concrete, the best using ash that strengthens concrete over time. it just goes to show the old saying is true: garbage in, garbage out.

C and C++ will always have their place for writing core libraries. and i'm a lot more comforatble managing my own memory (until i get Alzheimer's) than some new-college grad that's never heard of pointers. Even MS developers don't trust the garbage collection in the .NET languages. (i can't find the post right now...)

"But when was the last time you used C++ to write a line of business app or website?"

Hmmm. I guess that would have been last Friday, January 12 2007, when I was writing code for flight software application at a major aerospace corporation. For some odd reason, we aren't converting our insanely huge C/C++/Fortran codebase into Java, D, Ruby on Rails, Python, Perl, or whatever the current flavor-of-the-month language is...

I've been coding for about 20 years, in all sorts of languages. Assembler, Java, Smalltalk, JCL, REXX, C, C++, C#, Shell, Pascal, Perl, PHP, Ruby, TCL, Eiffel, Maple, Mathematica, Gauss...god knows what else, even VHDL's for FPGA's. Let me say that C++ is pretty great, and infact is what I've chosen to use for a number of new projects.

Here are some comments on assumptions on points above:

1) Many assume 'higher level language' needs to be 'slower'. That's just not true at all. That said, if it's slow in C++, it's likely your algorithm, while if it's slow in a high level language, it's probably that you're using convenience classes that are poorly suited for your problem domain.

2) It's true that a lot of programmers aren't formally trained anymore. If a programmer can't work out time complexity between a Quick Sort and a Bubble Sort (really basic questions), I don't hire them. Even if they'll be using a high level language. I've seen hundreds of thousands of dollars go up in smoke because programmers honestly didn't understand why the Java ArrayList behaved so poorly when used as a queue, and the queue size grew. Actually, change that: millions lost. High level langauges should be used for their expressive power, not as a crutch for people who shouldn't be programming commercially. It's ilke the comment above, "you don't know when you're hit".

3) Many high level languages are compromising in areas they shouldn't, letting programmers be lazy. If there's one problem with coders in high level languages, is that they don't seem to write much 'error checking' code. If something like VB or C# had Design by Contract built in (like Eiffel has) forced as part of the language, I'd be happier. I do know about Spec#, and other C# DBC extensions. Really, the language should be easy to use, but also do it's bit to enforce some quality.

4) Vista's way slow. I played with it yesterday and I could see delays in the icons on the start menu popping up. It's pretty pathetic. If I were Microsoft, I wouldn't be proud of it.

5) C# is a nice language. I'd rather people learn Smalltalk tho. Squeak is cool.

Only in the last three years have I spent more time with C++, and I'd have to say it's a pretty excellent language. C# is cute too, but it's performance isn't there. I wrote a test system in C, C#, and Ruby the other day. Ruby got 11,000 operations/sec, C# got 34,000 operations/sec, and C++ got 71,000 operations/sec. The C++ code compiled on Windows, Linux, and BSD without any warnings or code changes. It also used the least RAM.

Fast? Portable? CPU and Memory efficient? Do these things matter to anyone?

If you can't handle the power, just steer away from it. Don't badmouth C++ because of your inability to use it correctly.

I don't know, maybe it's just that I don't like to be kept in a little box that protects me from the real world, but I prefer using C++ over all these languages whenever possible. That said, I do think that some languages are more suitable for some tasks.

Citing Bjarne, "Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained." Just go to www.thedailywtf.com and you'll see that most posts come from Java and VB "programmers".

Myself, I'm eagerly waiting for the new C++ standard that will give us more template power and some new library additions (among other cool stuff). Read about it at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm

I'm wondering why people seem to think they can optimize code better than a mature optimizing compiler... In general, it's best to let the compiler do the work.

I also keep going back to the last point on the original post: which language best protects against human foibles? My answer would be the language that is the most readable and maintainable (good examples being Ada and Python). Almost all code will be read many more times than it will be written, and any long-lived system ends up with about 10% of the total cost in the development phase, and about 90% of the cost in the maintenance phase. Draw your own conclusions...

"The CLR will eventually destroy the class and force the connection closed, but you have no guarantee when the garbage collection on the object will actually happen."

http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/

One of my first Computer Science instructors told me that anyone who is a solid C++ programmer knows how to program and can pick up any language out there. This has held true since I heard it 10 years ago, with perhaps the only exception being Lisp (my favorite language to play with), which many OO programmers have issues with.

The reason C++ is a good language is because it makes better programmers of us all. From low-level understanding of how the machine works by figuring out how pointers work, to high level understanding of how objects and inheritance work, C++ covers it all. After spend 2 days trying to figure out why your program keeps saying "Segmentation Fault (Core Dump)", you learn/understand the importance of memory/pointer management. Struggling to write a linked list, and then learning about the STL makes you realize how important reusable code is.

Sure C++ is very difficult to learn and understand, but once you do, you have top to bottom knowledge and understanding of how a computer works. For all its faults, C++ should be a language every programmer has in his/her toolkit.

My $.02

Is it just me or has the bitchiness level on this board has gone up considerably in the new year? Jeff writes an entry on Vista's search feature and everybody and his brother jumps down his throat for being pro-ms.
He runs a post about C++ and it's relationship to newer languages and all the C++ people flip out and kick in condescending overdrive.

"Programmer laziness" is the dumbest phrase I hear on posts these days. The fact is you can get considerably more done in a given amount of time with the "cute" languages like C# and Java than you can with C++ or C. It's easier to recruit or train people in them to maintain the code. If you are writing an application that lends itself to such a language/platform wtf would you not use it?
I don't suppose any of you non-lazy types would bother to go to Ikea when you need a new coffee table. I bet you head out to the woods to chop down some trees and assemble it yourself. Damn you're cool. I'll just sit down with my lazy-self, kick my feet up on my new coffee table and drink a beer while you "real" programmers are off in the woods fighting with bears and chopping down trees (no chainsaws, just axes).
Of course you wouldn't rewrite all your legacy apps in a new language that makes no sense. Writing a whole new business application in C++ when C# or Java would do just as well? Well that's just a waste of time and money.

"One of my first Computer Science instructors told me that anyone who is a solid C++ programmer knows how to program and can pick up any language out there. This has held true since I heard it 10 years ago, with perhaps the only exception being Lisp (my favorite language to play with), which many OO programmers have issues with." --Bill

I'm glad you mentioned this. Maybe it's just me but I don't sense that Bjarne values productivity. If you can do C++, you're going to be able to spit out an web application using Ruby on Rails or ColdFusion in no time. But if you try doing it in C++, chances are one of these non-highly-trained-programmers are probably going to crank something out before the master C++ person. It's almost like he's arguing an experienced plumber should keep welding copper pipes together instead of using those fancy sleeves where they can just quickly crimp together 2 pipes. It's important to know the basics but don't run away from productivity lest you want to be out of work and out of business.

TheGeoff, so you don't agree that there is an increasing number of undereducated programmers, and that this is caused mainly because they are getting accustomed to have important tasks done for them? Read what Bjarne said in the quoted snippet, it's all true.

Like Bill Watts said, competent C++ developers can be competent in other languages quite easily, while it's not true the other way around.

I'm not saying I hate languages like C# (but yeah, I truly dislike Java and VB) but I'd say it's healthy to remain competent in languages like C++. It actually seems they put time to design C#. But if you're into the Managed stuff, I'd recommend getting into C++/CLI.

I think the one fatal flaw of C++ that prevents it from moving forward (in the guise of managed C++ or what have you) is its syntax. No one wants to write a parser for C++, and the toolsets for analyzing and generating C++ code are commensurately lacking.

I am on a legacy application that is C++, and I continue to do new development on it. My team is trying to evolve the app to .NET (you can't beat garbage collection and no memory corruption!) With managed C++ and Microsoft Visual Studio, I feel like the weird aunt that is invited to Thanksgiving out of guilt, and the hosts keep giving me subtle hints that it would be okay if I went home early. I will move to C# as soon as I can not because it has better constructs than C++, but because it has better tools.

Jeff, I think you've settled into a comfort groove where you feel C# has ample speed for your needs. From such a position it is understandable to sneer at C++ for trying harder than it's worth nowadays. But this "abundance" you're seeing is a mirage -- just imagine if every single application you use daily were written in a managed language. Visual Studio, firefox, winamp, Windows Explorer, Microsoft Office. The mental picture would be devastating. It's ok for one program to lag slightly when doing UI; it's a cataclysm when the whole system bends.

interesting. back in the 80s I used Lotus 1-2-3, starting with 1A. until 2.2(or 3) it was wholly assembler; thence C. I went from 2.01 (the last assembler release) to the C version. I could watch the screen morph, where before it just snapped. the machines were 8088, of course.

the moral of the story: there are 3 or 4 or 5 "levels" of programming, with 1-2-3 being one level up from systems programming. if that's what one means by "application programming", then C/C++/Assem is appropriate. OTOH, if a G/L (yet another) is what one means, then VB/C#/Delphi/etc. is appropriate. if one writes the G/L in C, one ends up writing a DSL, then the G/L. skip wheel inventing, and find a 4GL you like.

in between we find the java/C# world, which I've always thought were a bit schizo: trying to be both application and systems level.

Eli -- Delphi does have a 'form' of garbage collection: when you destroy an object, all objects that have this as their parent are destroyed first. E.g., when you dispose of a TForm object, all buttons, listboxes, etc. on the form are disposed of first.

Manually instantiated objects must be destroyed.

I have never had a problem with C++ and found it more elegant compared to C, but I think that once I discovered Ada (and I am talking the first iteration of Ada, not Ada 95) I picked that up and never looked back.

There is a WHOLE LOT of truth in the fact that if you are going to develop with a language as powerful as C, you need to know what you are doing... design design design. Same goes for a language that is C but now with more complicated interfaces that wrap underlying code... C++ becomes more dangerous in that respect.

No matter what language you program in, you can learn a lot about programming by learning another language (or culture).

Its difficult to argue for or against any language unless you know the subtleties of the language, cause these distinction to why you would choose one language over the another.

Comparing C# to C++ can be done at visual level by comparing syntax, but the way each handles the code you write is considerably different (compiled vs interpreted on a virtual machine).

Each language can present a solution to a problem. The context of the problem should help you decide what the appropriate language is to use . Most often the language of choice is the one you know as the computing solution to the problem is thought of in the languages that you know.

Klingon programmers incoming!

"C++ is difficult and for experienced programmers, experience at least with C. You can do whatever you want fast. But it is not for everyone."

"a programming language isn't dangerous. an uneducated programmer is dangerous. if you can't program well in something, either better your skills or stick to something you know."

"If you can't handle the power, just steer away from it. Don't badmouth C++ because of your inability to use it correctly."

All programmers make mistakes, Klingon programmers just don't admit it. If you use a great language, you'll make fewer mistakes whether you are a great programmer or not. Proper type safety (no memory corruption or segfaults) is something we want for 99.9% of everything - and for the rest you want assembly! We don't even have to sacrifice very much efficiency, for instance Eiffel and Ada can be written to be as fast as C if it's really that important.

It's all about Ye Olde Fortran.

Bjarne really sums it up with this quote:

"Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available"

When people say C# is high level or Java is high level what they really mean is that extensive class libraries are provided by the language vendor (.NET etc).

Several people have mentioned this, but all the software I use on a regular basis is written in C++, and I can't imagine what it would be like if they were written in some .NET language or Java or worse.

Firefox, Thunderbird, all the video games I play, music and video players, word processor, spreadsheet, audio recorder, Visual C++ Express, VS 2003, etc.

I could go on, but most of these applications task my processor, and would not be as snappy or responsive if written in anything other than C++. For awhile I was using Paint.NET, but it's slow, and I get annoyed with that, so I don't use it. Azureus, the Java bittorrent client, can't hold a candle to the C++-based candidates.

I program video games. There's no question about what language I use for that. Most next-gen consoles are faster than desktop computers, and those games will all be written in C++. Microsoft is pushing the XNA/C# thing for the XBOX 360, which is fine for hobbyists, but commercial game programmers know they can't use a runtime that freezes all threads to do extensive garbage collection and memory compacting for longer than 20 milliseconds. It kills the frame rate.

I estimate 98% of the time I am interacting with a computer, the software I am using was written in C++ and this is probably true for most people. So, how is the importance of C++ diminished?

How well does C++ protect me from myself? Well, I don't aim at my feet, so I rarely shoot them. In other words, when I instantiate objects on the heap, I allow smart pointers or STL containers to keep track of them and deal with memory management. I've worked on C# projects that need weird hacks to keep the runtime from freeing memory that is still being used. The .NET runtime with go ahead blow your leg off for you.

C and C++ aren't powerful, they are primitive. Because of this you have to work more, can create dangerous bugs more easily and will need more time to create a working application. Of course you can do everything in those languages - like you can in Assembler. And sometimes they may even be necessary - like Assembler. But that's not a sign of power.

All this "If C/C++ is to hard then you are to weak" gibberish only shows that those people never tried to create real applications in different languages. It's now about being 'hard', it's about getting the job done. People who choose the wrong tools simply aren't professionals.

My own experience with people having to implement something, let's call them 'developers', is that they are struggling with the concepts, not so much the language. Take the concept of a virtual base class, of an asynchronous event, or a reference-counted pointer. some languages let you side-step these because they have their management built-in (e.g. java for reference counting) but if you need to optimize for memory usage, you need to still understand this concept so that you can (e.g. java) set the object to 'null' so the garbage collector can take it away when come its time. Pointer aliasing exists in Java, Perl as well, it's just less apparent. And these are the things that fresh students have a harder time to wrestle with, and therefore leading to poorly implemented code, whatever the language. I think that is what Bjarne was mentioning, just that he looked at it from the C++ perspective where these fault very quickly end up in segmentation faults and the likes. In Java, this ends-up as the 250MB resident RAM application, in Perl as the garbage sorted hash, and maybe as an exception in Python. It's like explaining a car's manual shift gearbox to somebody having driven an automatic all along. You'll have a hard time explaining the usefulness of the clutch...

Free Sign Up Today!
100% Free International dating service
100% Free Find & Talk with other members in on-line
100% Free Instant creating Your own personal profile

http://www.mybelovednet.com/gateway.php

Bjarne is absolutely spot-on with his analysis. C++ is an incredibly powerful toolkit, but the mistake that many have made in the past (including my own organisation) is to attempt to build business apps directly from the lowest level components provided by the language. This is cumbersome, which is why it has been pushed from this niche by VB6, Java and the .NET languages. The correct way to build systems is by providing the basic abstractions (starting with strings, collections, memory management) and build on top of these in layers of increasing abstraction; Java and like languages provide this basic layer "out of the box", which feature has been instrumental in their success.
The sad irony is that we are only now seeing - too late - these sort of facilities standardising in C++, with the advent of STL and boost. Read comp.lang.c++ and you'll see that a lot of the gurus there never go anywhere near a raw pointer, a delete statement or (god forbid) a C-style array, they have all this stuff wrapped - layers of abstraction again.
The sad thing is that by defecting to Java, C# etc we have also surrendered the wonderful expressive power and flexibility of C++; I certainly miss it.
One last point: C++/CLI would appear to offer the best of both worlds, but I see very little evidence of its use - another case of missing the boat I fear.

Use Qt in conjunction with C++ and you evade it's downsides without losing the benefits of this great language. The resulting code will retain the efficency and performance of c++ but will at the same time be easier to read and comprehend since it is much more 'high-level' due to the elegance of the Qt-Library.

C++ is only difficult to people who don't take the time to grasp age=old computing fundamentals. As such, a lot of modern programmers can't even do binary arithmetic and whether you like it or not computing will alwats be 1's and 0'.

Anyway, the point I try to make is that the beauty of C++ is that you can code _within the user's constraints_. All these fancy new languages (note that I code professionally in C# so I am not stuck in the past) leave the developer making brash assumptions that people are happy to install 20+MB runtimes and other such dependencies just to install their app.

For my own shareware apps, there is no other choice than C++. Of course where necessary I mix it with the native frameworks depending on the platform I target. eg. A windows version of my app uses WTL/C++ yet the Mac port is Cocoa/Obj-C for UI and C++ for the model classes. Works beautifully because I took the time out long ago to work out what I was doing!

Just decided to have a quick look for benchmarks of c++ vs .net

http://blogs.msdn.com/jonathanh/archive/2005/05/20/420634.aspx

pretty interesting - c# won until c++ had been optimised so far that the 60ms startup lost it the race

C++ is too flexible. Yes, in my opinion it's a disadvantage. The most terrible thing is a possibility to inherit the child class from many parent classes. Sometimes, when the application design has to be changed during the implementation, eg. new facts have been identified or because of the inproper design (and - to be honest - we meet such situations very often, although everyone will agree, it's "not good") or the whole design is more "paper like concept" (looking nice on the papaer but not seriously implementable) than "reality model" the implemented application class model seems to be total mess (and many times far away from design concepts). I mean, you can do too many bad things with C++ as in fact it is not to restrictive language. And then, let think about a guy implementing an application for a couple of years, doing total mess, using all the features of C++ without any concept, just to solve the problem and "progress with the schedule"... The guy thinking - "if it is working, it is ok and we don't have to change anything". Then, imagine the guy will change the job and you will have to take care about all this mess and crap. I thing it's impossible to solve many problems with the inproper design and implementation of C++ applications in a sensible period of time. Sometimes it looks, that the best idea is to design and implement the whole thing again, but of course such move is not possible in reality. I think the programming languages have to be more restrictive than flexible. At the end... it's better to think twice because of some restrictions than avoiding them with the manic-like solutions with the usage of "advanced" features of C++. And - to be more honest - C++ is good, but not for all tasks we can imagine (just because "it's faster than Java" and also multiplatform). We don't need the swiss-army-knifes, like plumbers we have to use the set of tools, like : pillers, hammers, cutters, threaders, welding blowpipes and so on... We need to choice a proper language for specific problem. I think the problem with C++ is that many people consider this language as good for almost everything. There are no flexible tools - you cannot hammer in the nails with the usage of pillers, as you cannot write the web application with the usage of C++ (but you can with ASP.NET, some specific J2EE standards or PHP - depending on the complexity of such web application of course).

That's all from me.

"at a time where the degree of effective formal education of the average software developer has declined"
Yes, I work as a tech lead in a major sw company that uses C++
I have to review a lot of C++ code and interview ppl on their C++ knowledge. bottom line is C++ has gazillion amount of accidental complexity, that distracts from solving the problem.
All teh C++ guru I know, are just that C++ guru, they know nothing else, they're not the guys who can come up with a practical solution fast. They always always always come up with a massively overengineered solution, whose performance sucks and that is totally impossible to maintain.
I've been through so many "refactoring" exercise once the dude who wrote the stuff has left and we find that it is always faster to reimplement than trying to fugure it out.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."
That is so so so so wrong, C++ makes it much easier to shoot yourself in the foot and when you do, there's nothing left of you, leg body arse... all gone.

Gimme C, perl, Javascript, LISP everyday, but C++ for me has sucked the joy out of programming

I would agree with Tragomaskalos, where "modern C++" doesn't have C arrays or fully-explicit memory management (it is still somewhat explicit, as you can discern between a single-owner or shared ownership strong reference, or a weak reference, for example). You don't go anywhere near a "delete" statement, and buffer overflows are a rare occurrence with vectors and such.

The much hated C++-style casts are at least greppable (and I find their ugliness to be a *feature*, you know something's awful when you see one!) as well as more accurate (static_cast does notmagically and silently turning into a reinterpret_cast, which would most likely introduce a bug, for example).

You still have the lower-level C-style constructs available, for those times you really need them (which is just about never, if you're not doing system programming). One could say that not having them at all is probably best, but I find idiots somehow manage to write crap code no matter what language you give them, so it might as well be a more capable language.

This way, you can also notice the people with blown off legs and fire them. ;-)

C++ is just C with object structures, I'm guessing all C++ compilers actually still at some point output C code.

Personally I love C and C++. Yes its complex, probably more complex than is really good.

Also pretty much no one uses it, but its not really the languages fault. Blame it on Microsoft, no one wanted to write MFC applications, and Microsoft openly ignored the standard, and implemented a lot of crap that people didnt/couldnt/wouldnt/shouldnt use.

Who's got time to figure out how to write code in a language that doesnt have a standard implementation that can be used to build real applications. MFC was just too hard, weird, too Microsoft -- it killed the language.

C# is just Java with the names changed to protect the lawyers, I dont consider it a derivative. But I like it, even though I dont use it.

Mostly, I find PERL, AWK, Python, and other scripting languages get it done for me these days. Its just easier, and most stuff i want to do I want to automate and a GUI is in the way.

I still love you C++, but your time has passed.

I guess another way to look at things these days is that with so many RAD desktop/web software being developed, a modern language targeted for that end point is needed.

Low level work requires C/C++, but these days more work is done at a high level (i.e. Writing an AJAX web application, rather than writing a web browser in C++)

Really this topic shows more about human psychology!

With people:
* Defending their choice of language
* Taking digs at other language
* Attacking each other

When deep down we all know the basic truth, with is:
* There are different programming languages
* There are different types of software to be written with those languages

There is no right or wrong, only different choices with different outcomes.

You are a fucking idiot, c++ is supposed to be for expert programmers only because noobs like you dont need to use it. Youre the stupidest person i've ever seen, or read.

There sure is a lot of defensiveness around C++, but that's already been pointed out.

I agree that C++ has very few uses nowadays where C# (or another common language) would be a better choice. But Stroustrup's point about uneducated programmers is valid. As far as I'm concerned, language is irrelevant compared to skill with programming, and we have too little skill going into increasingly complex problems.

When a programming language don't help you to solve a problem, then it isn't appropiate to solve it.
When a programming language confuses you in solving a problem, then it is not the best choice.
Now, when the programming language is just a tool, and you don't need to worry about the language itself, and only with the problem that you are trying to solve, then this programming language is the best choice that you can do.

For example, in high level applications, how many times I forgot to put an "&" in ATL WIN32 API variables, and it give me a lot of problems that made me wast a lot of time and money. Now, it's normal to forgot this, we are humans, and humans forget things. Then, C++ doesn't help me with any warnings (W4) or anything to solve this problem.

C++, in my opnion, isn't the best human friendly language to solve high level problems. There is languages that do this in a better way.

This whole topic is laughable. About every month or so the VB and Java camp spit out propaganda against C/C++. This time because Ruby has Java on the run.

Let's take this article's argument even further. Why use Java? It's harder than some other languages. The simple fact, which Stroustrup made clear, is it encourages specialization.

Look at Java, for example. As long as a Java application is idle 99% of the time it's ok to use Java. Otherwise use C/C++. That's the reputation that specialization awards.

Stroustrup is clearly frustrated with the state of Computer Science in academia. Most universities switched to Java in the classroom about 7 to 8 years ago. Not because Java is a better language but because the professors got lazy and didn't want to spend anytime teaching the C++ language. This narrow minded philosophy has lead us straight to where we are now. A small army of Java disciples suffering from something akin to C++ envy. Now we have to suffer with things like slow phone systems 'proudly' written in Java.

Graham

Give me a language that is better for real time 3d graphics programming, and I will gladly use it. Not everyone has moved on to the web.

A number of people seem to be saying the same thing and that is, C++ isn't the problem, the programmer is the problem. The argument seems to be if you can't solve your problem in C++ then you aren't good enough to use it.
I think this line of thinking is generally one that stunts progression. The problems we are trying to solve today are, arguably, many orders of magnitude more difficult than those we were solving 10 or 20 years ago. When C++ was created did anyone think of desktops with multiple cores? Probably not. Given this increased complexity, perhaps C++'s expressiveness is not enough anymore. C++ is not going anywhere due to legacy code, however when making a new project one should think hard and long about what benefits the various languages will give them. To put it in an analogy, construction has come a long way from slave labor, now we have giant machines to do our work. They can move in a single shovelful as much as a hundred men can. They move a bulk and of the problem and then we use smaller and more refined tools for the other parts.
I don't think making languages 'easier' is meant to make less skilled people able to program, no, I think it is meant to let experts solve more complex and interesting problems. Writing an IRC client in C++ is one thing, however building a large, fault tolerant application that needs to have defined state throughout its lifetime is different, and I would not like to do that in C++.

One thing to also remember with all of these languages, is marketing.

When .NET, which I am using to encompass C#, et.al., has Microsoft's marketing team behind it, how many "new" programmers are going to head to SmallTalk or Java? At lot less.

When Java has Sun behind it, plus their other Sun Studio product which includes C/C++ for free, how many of the left over "new" programmers are going to head there? Not quite as many.

That said:

When a business needs to have an B2B web service and web protal created in 2 months, who are they going to want to work with AND add supportability for any other programmer to step in at anytime? A C# ASP.NET programmer who can turn out that app in possibly 1/2 the time or a C or C++ programmer who can maybe get it out on time?

What if a cell phone manufacturer needed a new GreenNose driver that is going to blow away the competition and make it to market before their biggest competitor? The C# programmer who might be able to fit the app on the cell phone's limited storage space or the C programmer who can make it fit and leave room for that spreadsheet app the other department is working on PLUS crank it out in half the time?

I've said it before, yes the tool may do the job, but is it the right tool for the job?

I totally agree that knowledge of other languages is important, but I also agree that it isn't necessary. I can read C, C++, Java, or any number of other languages, and with time, could even code in them. Anything can happen with practice AND documentation.

One of the other things that makes MS technologies "better" is the fact of support. They have excellent documentation, support forums, training, and a user base that rivals any other language produced by another company or by the open source world. This a cannot be denied.

It seems to me, there are two types of "languages": a) of the Turing camp (the FULLY ORACLE-SQL-Persisted-SWI-Prolog and ASSEMBLERs), and b) the fast, straight, bladed procedural (compiled) languages ala C/C++/Haskell/Ruby/Most_LISPs/Mercury..u name it. The basic end-to-end-runtime system, buddy, that's the very idea behind every language philosophy. And C++? Well.. SEX. Yeah, sex, sex, sex, sex, sex. The easiest way to overcome a problem is to make it a bit more.. bisexual. Add libraries. Mix it, blend it with stuff like LLVM, rt_ctiny()...even Factor..

No, bytecode seems to be so...i dont know...rude. I mean, something like a C# parser, or a Java one or VB over a bytesomething....yeah whatever

i gotta go, oh happy new year ! :-)

I work 50/50 C++ and JavaScript - C++ simulation models and an XUL based front end. Prior to that I've used Java both for both server and UI work, and a bit of C, Fortran, Pascal, various assembler, XSLT and Matlab. The use of C++ components with a scripting front end is not uncommon - most of Mozilla's products are defined that way, as are many COM applications.

For modelling and simulation, if you have something processor heavy it's likely to be mathematical. A good programmer can write Fortran in any language - well thought out algorithms operating mostly on primitive arrays. For that kind of code, with Java 1.4 you got better performance than MSVC++6 C; now VS2005 C is better than 1.6. C++ using stl fares worse than Java for tests such as SciMark. This is for modelling, not real-time simulation.

One of the modelling systems I've been called to work on cost 500,000 UKP per year in processor hours (the company was renting a legacy mainframe), so unless you're a multi-millionaire we're not in an era of abundance. On the other extreme, OLPC is a 100 dollar platform so again requires tight code.

Once you stop writing Fortran (and most sane people want to), the performance hits you get with Java or C++ seem to come from exploiting OO's information hiding, so the compiler is not able to optimise across objects. Sometimes trading hot-spot optimisation for whole program optimisation pays, sometimes it doesn't - for example inlining the most common case at runtime. The Fortress language, which runs on the JVM and is targetted at M&S, is addressing this by flattening the program; I've also had success using model-driven development pipelines for generating flat code from high level maths models.

One weakness in C++ is that its templating system is not a very good model for meta-programming; Java and C# don't even try, so there's more external code generation options. Object oriented languages also have introspection and reflection, which C++ lacks, so I've ended up having to add them to every large C++ system I've worked on.

WRT RAII and garbage collector scheduling destruction, C# provides the 'using' statement that gives similar scope-delimited resource life-cycle semantics. It's not a hard problem.

I don't see C++ moving from realtime simulation yet (and that includes many video games, though there is use of scripting languages for AI and overall gameplay etc.) - it does most of what you want well enough, and lets you optimise for a traditional machine - until it's pushed off by a language that can handle multi-core processors better.

If you use source control, you have to see this YouTube video! ROFL!

http://www.youtube.com/watch?v=msDuQoKqysw

I like C# a lot too, but it by no means replaces C++. There are a number of things that you can't do in C# that requires you to do a p/invoke to C++ code. This is especially true when programming for when programming in C# using the .NET Compact Framework on a Windows CE device.

The largest problem with C++ is that it is too easy to make mistakes. People say "You must be a competent programmer, then that won't happen", suggesting that they are such a competent programmer. NO ONE can just write bug free code, particularly in C/C++. The OOP system gives a facade of high levelness (leading to misconceptions such as a GC and safety), but really its just a macro system. The odd bit about this macro system is that it didn't really do stuff that had been repetitious in C code before.

The other problem with it is that the 'proper' expression of solutions tend to be much longer than the dumb ones, and tend to have bad interfaces to boot. Worse yet is the tendancy towards preoptimization - because you can, you do. In the end you get longwinded, improper, preoptimized code.

Except for the preoptimization point, the previous paragraph may also be applied to such languages as C# and Java, which force upon you the OOP model as well as longwinded expression of simple concepts.

PS - that thing on fortress above, It does look like a very interesting language, but it doesn't necessarily target just JVM. That's just the initial impl. They are going to target machine code, and ramp up performance.

How can I resist adding my own comment to this burgeoning list when everybody else and their mother has already chipped in with their two cents? I have been writing embedded code for years. I do as much as I can in C, occasionally I have to deal with assembly language. C++ never appealed to me, I never found any advantage. Of course, most of the stuff I write is pretty simple minded.

I have found very little need for C++, however, I have found the need for low level languages like C or assembler from time to time as well as higher level languages like Ruby or Java. C++ just seems to fall in the middle when I personally have not needed to develop anything. Perhaps we need to look at this a little differently:

1) There will be programmers who need to know the inner workings of the machine and be proficient with bit-twiddling. These programmers will write the core of the OS, applications, and back end processing and data storage as well as complex, speed optimized routines.
2) There will be programmers who need to understand more of the business and functional processes then express these as code to implement them.

Very rarely will these two cross. Who would want them to? Do you really think that the programmers designing the internal workings of an RDBMS would really do well talking to the accountants about the char of accounts? Would you really expect someone with 90% of the knowledge of an accountant to be able to use binary math or read hex?

Perhaps the message here is to use the right tool for the job, not only the right language, but also the right programmer.

The truly great programmers will understand how all of the logic gates work and how various methods of memory allocation will affect performance. These people are very important.

However, others will fully understand the business domain, and often they will be best served by a language that insulates them from the reality of how it all happens. Luckily, they will speak enough tech to communicate with the low level programmers to handle things when they need to.

Looking at this from the game perspective: There are those who write the 3d rendering engine, but there are also others that write story lines, do artwork, and record audio. The jobs are all important, but different.

The C++ programmer comments are quite interesting. None seem to remember why programming languages exist.

They exist to do useful things for PEOPLE.

PEOPLE. Remember those things?

Sometimes I need a power screwdriver with 12 specialty tips plus a dremel tool with a set of plans to do a job. Other times, a hammer and some intuition will do. You could put the dremel, drill and plan holder and pencil holder into one tool much like C++ tries to put everything into one tool. Anyone out there own anything like that?

As for complexity, they discuss it like it's a *good* thing, rather than simply an occasionally unavoidable thing. I chalk this up to machismo rather than intelligence. In humans, intelligence expresses itself as using the easiest, most appropriate tool for the job.

So I'll stick with generic freely downloadable C# or VB (which at this point are more or less the same) which run on that much hated, and ubiquitous Windows OS for most work and save c++ for those ever fewer occasions when it provides cost-effective utility.

Cheers!
Ian

Well, with 110+ comments, this will likely be lost in the haystack, but here goes...

What a bunch of arrogant, puffed up assholes most of you are. Nothing like stroking the old ego, huh? Or the classic, "In my day, we had to...". All the talk about being threatened by C++, and yet, the mighty are freaking out that C++ is not the be all, end all. Give me a break.

Now, of course rigor and hard science disciplines should also exist. And they should set a very high bar. As stated before, Doctors, Engineers, and Scientists should not be rolling out of weekend course. I don't think this was being proposed by the original post.

But, I would put forth the example of the Web. Here, through HTML and other easy means, a wealth of wonders has been drawn out from the average person because the technology that was for so long only available in the hallowed halls of academia became liberated. In case you couldn't see it from your Ivory Towers, this is a good thing!

Imagine, a bunch of pompous cocks bitching about Gutenburg's press. "Oh, look! Now every half-wit with an opinion will be publishing books! It's outrageous! You should have to spend years and years in a monastery, learning to painstakingly illuminate by hand!".

Here's some advice: Step away from the keyboard and go do something you've never done before, and enjoy the wonder of being a novice, discovering new and interesting things. It'll do you some good.

I'm surprised that no one has brought up the side by side comparison done with Raymond Chen's Chinese/English dictionary reader. Jeff even blogged about it:
http://www.codinghorror.com/blog/archives/000299.html

Yeah, C++ will perform better than C#, but productivity-wise, it sucks. When performance is a primary concern and you've got some intensive tasks that the application will be doing(games, drafting software, etc), then of course C++ will be the way to go. However, that enterprise web application will be better off written in C# due to the huge boost in productivity and negligible performance penalty.

This discussion really isn't that complicated. You don't drive nails with a sledge hammer. Different applications require different tools. It's not about C++ vs C#.

I'm tired of hearing that C++ is an unproductive language. It depends on the libraries that are available to you. I can be just as productive, and maybe even a little more productive, using c++ with Qt for builing GUI apps than with java. C++ certainly isn't the best tool for every job, but most people who dislike it are a bunch of goddam whinners. If you think C++ will work for you for a specific task, then use it. If not, use something else. And even if you end up using java, c#, perl, etc. 99% of the time, you should learn to write code in a language like c++ or c to enhance your knowlege of how software works. One of these days when I have enough spare time, I'm planning on learning assembly just for the sake of having a better understanding of how software works. I may never use assembly for real world code, but it might help me write better code in other languages. If nothing else, learning a low level language will give you another tool to use in the future in case you do end up having to do some low level stuff.

I'm an old C++ programmer having cut my teeth with Borland's initial incarnations of the language and moving up to MS C++.

C++ is still useful however, in my opinion, there are better solutions for high level apps.

The good thing is that you can write libraries in it for the stuff that has to be fast, efficient or whatever weird thing it has to do and then bind them to your C#, VB, Java or whatever high level language.

I think that's the way the majority of C++ development will go in the future.

Regards,

He stated that people don't know where to find libraries that exist. So, for student that is currently using C++ where is there a good place to find such libraries. For example if I wanted to create a Btree. Is there a library out there which contains a template for this type of file structure? I guess what I am saying is that the STL for C++ needs to be updated.

"If a language is deemed "easier" it automatically requires less brains to do the job."

A wise programmer will always use an "easier" language when it meets his or her needs. Unless said programmer is an academe or for some other reason the final product and programmer time doesn't matter.

I guess the best way to find libraries for specific tasks is to just google them. Unlike the class library for java and other languages, it is intended that c++'s STL not be bloated with lots of stuff. That helps keep c++ a generic programming language. I think some of the STL containers use btrees internally. Also, keep in mind that you can use any c library with c++. There may be some exceptions to this, but I don't know of any.

"Delphi... has very good garbage collection"

Huh???????

"Delphi remains the best Win32 dev tool in existence, and a decent .NET dev platform. One which even allows Win32 Delphi apps to be recompiled for .NET, preserving the developer's code base. Something MS did not make available for all the VB and C++ apps that needed to be converted to .NET."

True enough. I still hate the language with a passion. I worked with C# for only 3 weeks before falling in love with it and realizing all the drawbacks of pascal.

"I guess what I am saying is that the STL for C++ needs to be updated."

Yes, this is no discovery. The standard library is going to be updated for the next standard with useful things like sockets and threads.

"Here, through HTML and other easy means, a wealth of wonders has been drawn out from the average person because the technology that was for so long only available in the hallowed halls of academia became liberated. In case you couldn't see it from your Ivory Towers, this is a good thing!"

I think no one can argue the fact that an increasing number of professional developers are undereducated in programming. Hey, if you're only a hobbyist programmer that develops unimportant stuff, what do I care if you're an incompetent programmer? Professional programmers are the ones who should be more knowledgeable. That's what we're arguing about. That's what Bjarne was addressing.

"We're developers, not English Teachers... You obviously can't write a lick of real code if you spent the time to worry about the grammar."

Disagree; written English is an analog of code. One who expresses himself well in code should be able to do so in their social language as well. Nitpickiness in grammar and nitpickiness in code go hand in hand.

listen here you young wippersnapper noobies!!! I've been a programmer eversince you were in diapers and suckling on your poor mamas nipple.Back in my day we used lotus, pascal and just plain old binary and that's the way it was and we liked it.I got one word for all of u youngsters and that's that "Your all totally wrong!". Learn the basics!! and I don't care if it kills You and by the way, FUCK PRODUCTIVITY!!..We used to walk to the computer lab 5 miles uphill in the snow, barefooted everyday just to write programs that You ingrates dismiss with all of your fancy schmanzy codes and opinions. If I had my way I'd settle this the old fashion way and challenge every one of You to an old fashion code write-off. I've written off the best of em , from jobs to gates...I even took out balmer back in 78 back when he was a zitty faced punk in braces and headgear. if any of You young punks want to try me then..Bring it BIATCHES..

"We're developers, not English Teachers... Wut a dumm risponse."

Oh dear. Yet another young wanker who thinks that proper English doesn't matter. Grow up, sonny boy. You probably don't even know when to use "its" and "it's" correctly, and I bet you spell definitely "definately". And the worst thing is, you think it doesn't matter.

No wonder most software is in such a dire state. If you can't get the details right, what hope is there for the big picture?

Software engineering: a contradiction in terms.

"But when was the last time you used C++ to write a [...] website?"

I've written several websites using C++. For example an SMB search engine. It is very good at integrating things - an HTML template library, SQL library, CGI library.

"Because it can do all these things, it's complicated and dangerous."

Dangerous links to buffer_overflow. That's really only a valid criticism for C and for stupid programmers. C++ has std::string and std::vector.

Sorry Jeff; While I usually agree with everything you say, you've totally missed the boat here.

Jeff, are you just writing these pieces just to sit back and laugh at so many whacked-out responses and get your page rankings up?

It works!

@Steve

You are incorrect. That is not garbage collection but a simple parent-child relationship in the Delphi VCL. It is present in nearly every GUI library I have used, including Motif (C), VCL (Delphi)and Qt (C++).

The parent-child pattern is a paradigm common in many GUI toolkits and has nothing to do with garbage collection.

There is nothing like C++ to start a flame war.

Why does everyone forget about people who write programs that make heavy use of numeric computation? Many of these people are still writing in Fortran. Though, C++ is great for this too.

Good static analysis can really help C++. Every criticism of C++ is true and almost all of the time that's how it was designed. It's kind of like calling a dog a dog... You should already know what it is.

The optional garbage collection in C++09 looks interesting.

Imho, it is usually poor design and coding practice that leads to unnecessary complexity, not a programming language. You can make a mess in Java just as quick as you can in C++.

Using more than one language in a project is good [tm].

Daniel: You can code cross platform with C#, Mono has come on leaps and bounds. You do have to put the extra effort of making sure your code is fully compatible with Mono and that you don’t use anything windows specific. You don't get anything for free ;)

I know I know...I just doubt it works properly as C# / .Net have been designed for Windows (and possible Windows Mobile). Java has strong support for Linux with Free Application Servers, Web Servers, Database Backends etc...is C# / Mono really on par with that??

" "But when was the last time you used C++ to write a line of business app or website?"

Hmmm. I guess that would have been last Friday, January 12 2007, when I was writing code for flight software application at a major aerospace corporation."

Not sure what the definition of "line of business" is, but I don't think flight software qualifies. You're doing the exact kind of program most posters recommend for C++. It ain't like no web site.

It is not just that one should select the right tool for the job, one must also choose from tools that one knows how to use effectively and eschew jobs that require tools for which he eschews training.

It is an absolute truth that C and C++ require the programmer to handle his own memory management. A well trained programmer not only is capable of this, but uses this to his advantage.

The poster's comment regarding the "age of abundance" is only a partial truth at best. There are plenty of programs which continue to be resource hogs. The ability to micro-manage those resources can be the difference between a usable interface/program and a nuisance application. Bill Gates once said something along the lines of "640KB is more memory than anyone will ever need," so apparently this is not the first age of abundance.

In fact for the last 20 years we have been in an age of abundance with processors, memory and cost improving by factors of around two annually. Yet, most do not have a computer ready for the newest MS operating system, Vista. In fact many computers purchased just in the last year are not Vista capable and those that are, are so minimally ready that I expect kernel thrashing (sic)*.

And what programmar that has written a Java routine that ran for 13 minutes crunching a solution wouldn't be excited to have the same functionality in C++ with a 1 minute running time. Java is often useful for a rapid prototype but then a C++ solution can provide optimized results.

We have projects that run for days, even months in the programming industry. Speed is important. Will always be important. No matter how much memory we have we seem to be able to fill it. I remember when 20MB drives were considered large. In 10 years I expect most of us to have 2TB or more at our disposal. We will use it all.

There can be no age of abundance until we prove P==NP. And this can't happen until we have quantum computers. Even then we will have even larger problems to solve.

C++ is a great tool. I like it better than C. I often use it and interface with existing C programs. At times I prefer it to Java but when I want platform freedom and a GUI, I trust Java. Even with Java it's important to understand memory concepts. GC is no assurance that memory will be used optimally. Occassionaly one must let go of the object and sometimes one has to call gc() directly.

* Kernel thrashing is, of course, literally impossible (by definition kernels remain in memory). My point is that the Vista OS requires enormous amounts of RAM by today's "abundant" standards.

Nice post and few daring conclusions :). I agree with some observations but not all, few points which I totally disagree..

First commenting about website development using C++ is inappropriate as there are alternate language for it. C++ is a computer programming language and has nothing to do with how to render an webpage. Although backend HTML render engine in most probability is C++.

Secondly, C++ is not dead. Most of the gaming engine, computational apps, libraries or simulation code is in C++ (most of it).

Thirdly, I am not sure we are in the era of abundance, philosophy that you have presented - being in era of abundance allows us to design lazily is not an appropriate argument. Why don't I see my machine being booted under 5 sec and OS running blazingly fast?? Our task are still the same - documenting, emailing, browsing and some business app. Still we are slowing down everyday.

I don't deny the need for C# or similar language but whenever you have to build any business app - most of the time is C++/C, just to ensure you can do what you want but not limited by some other constrains :)

-km

I have 7 .NET applications idling, including Sharpreader (ugh) and a couple of instances of Paint.NET. No percievable slowdown in any of my applications, .NET or otherwise. Even when I start loading files (with Paint.NET does the fastest I've seen btw) or doing process intensive task there is no slowdown relative to a native application.
My conclusion? I would have no problem running managed applications if people wrote more that I wanted.

And, well i really like the whole Plan9/Alef thing. It's open, small, you can understand it and you can modify it at any given time. Very, very easy to use...That's the real power of C and C++. The environment.. . And the possibility to make that conversation between you, the compiler... and the OS. I mean it’s so transparent ... C/C++ is not a bad thing but you need the right environment, the compiler and the OS must be 1 really. That’s the “problem” with commercial systems like Windows... They're interfaces, politics, philosophies and a million other things.....but they can't really make the subjective connection between the programmer, the language, and the OS. I don't know, maybe the first step should be to make the end users - programmers...

Cement? Why use cement? I find that chewed gum and masking tape take care of most problems just long enough for it to become someone else's problem.
Confucious say: If it's not my problem it doesn't exist.
And remember - Ideas are dangerous. The more usefule the idea, the more dangerous. Especially in the incompetent hands, you twiddle-fingers.