The Problem With C++

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).

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.

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?

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#.