Submitted by “MIT’s Technology Review recently interviewed Bjarne Stroustrup in a two-part article (part one, part two). You may know Bjarne as the inventor of the C++ programming language. Indeed, he even maintains a comprehensive C++ FAQ that answers every imaginable C++ question. Here are a few select quotes from the interview that I found notable.”
I can’t help but feel that C++ is the worst thing to happen in computing.
So much complexity, for marginal benefit.
I can’t help but feel that C++ is the worst thing to happen in computing.
So much complexity, for marginal benefit.
C++ is bad that way, but both PL/1 and ADA have it beat for excess complexity.
You’re obviously a moron.
Sorry Cozby – I feel otherwise.
what Barjne now thinks introduced ‘generics’ into C++ in ’90.
It wasn’t really until Alex Stepanov suggested what became STL to Andy Koenig and Andy convinced Alex to submit it to the committee that anyone thought of templates as enabling generic programming, and even then there were a lot of problems. I think that happened in 95.
Anyway, 10 years on, it’s not at all obvious that the small reuse advantage from generics is worth the language complexity they added to C++ as an add on.
Maybe in a language that was designed with genericity from the start, but not as a bolt on to “C with classes.”
From my understanding templates are based on macros and thus not part of the language itself but the macro language which translates C++ template code into C++ proper. Feel free to correct me if I’m wrong.
Templates are very like macros, except that the language semantics understands some of the details about them.
Pretty much everything in C++ prior to the first standard was designed so that a preprocessor (the famous cfront) could turn it into C code to be compiled by your favorite C compiler.
If C++ is so bad, why is there still so much software being written with it?
Even MS, who are saying .Net is all that and a bag of chips, still writes the the majority of it’s titles in C++.
Most of Google’s stuff is written in C++.
Adobe’s stuff, too.
Most browsers are written in C++.
Open Office – C++
KDE – C++
AS400 – C++
Most video games – C++
Most over the counter software you buy at CompUSA, Best Buy, and the like – C++
A large portion of the embedded market – C++.
Yup, C++ is complex and somewhat difficult to learn and master.
But it’s quite obviously still a very powerful and effective language.
Would I use C++ for Web Apps? Of course not.
General in house business Apps? Nope.
For all that, it’s Java and .Net.
If C++ is so bad, why is there still so much software being written with it?
Because for large-scale apps like full-blown word processors that you don’t want to run at a snail’s pace, nobody has made anything better yet. That doesn’t mean that C++ doesn’t suck, just that everything else sucks more
I agree to you!
The people always hate what is difficult to learn (e.g. math, chemistry or physics).
C++ has shown its power and capabilities with a lot of huge scale software; software with a complexity and size that almost none of us will always be able to build; thus, the problem is not C++, the problem is us!!!
“If C++ is so bad, why is there still so much software being written with it?” Because that is the primary language tough in colleges. Most people are not willing to learn something new they will stick to whatever language they know.
MS, Google, Adobe… Because companies can hire good well trained C++ rather cheaply, with people who have college degrees. Untrained programmers who often learn to program on their own will often use other languages. But if you want a large set of skilled programmers then go with C/C++.
Open Source Apps. Same concept as the Commercial Apps. As well College students are the best supporters to Open Source because they have the time and resources without having to worry about making a buck.
Small Projects or CompUSA Apps. Because a lot of them are from a hot shot kid out of college who was taught C++ so they program in C++.
C++ Popularity is not because it is good at what it does. It is popular because people have been taught that it was good. Thus continue the endless cycle.
We have a slew of other languages out there that can be better then C++ for any one thing. But because people don’t want to change they stick with it. Programmers are just as Closed Minded and Stupid as the rest of the general population, so why do you think they will make smart decisions and choose the right programming language for the job.
You might be a little older than me, but the primary language taught in most university CS programs is now Java. When I took the advanced placement test in high school, mine was the last year they did the test in C++. They now do it in Java.
Looking at the course catalog for my alma mater, I don’t see a single CS course in C++ (some are open-language and allow C++). The vast majority of my classes were in C (with some introductory courses in Java), and the professors emphasized that OOP is easy to implement in straight C using structures and function pointers/tables.
Maybe this is a sign that while C++ is popular now because many 25-40-year-old developers out in the field cut their teeth (or rather shot themselves in the foot) on C++, but the <25 crowd is more comfortable with Java.
And how do you feel about it?
I mean, if Java has became in the most popular language in CS programs at the university… who will write Operating Systems? who will write drivers and all the always needed low level stuff?
Java is a cool language, but hides a lot of things that every CS student should know and manage (pointers, function pointers, memory deallocation, etc.)… if the student never needs to handle those things by his own, he will become unable to handle them someday.
If C++ is so bad, why is there still so much software being written with it?
Inertia is one of the biggest factors in computing. After all, if the Win32 API is so bad that Microsoft is developing .NET to make up for its defects, why is there still so much software being written with it?
To quote the article:
C++ has indeed become too “expert friendly” at a time where the degree of effective formal education of the average software developer has declined.
They haven’t spent the time learning a decent language. Please don’t use the word “power” in reference to languages; it doesn’t make much sense.
If C++ is so bad, why is there still so much software being written with it?
Why do people still drink Molson, Budweiser and Heineken even though all 3 are all watered down beers? Answer: It’s what was there are the time and it caught on.
We all know C++ is crap. It’s got horrible syntax met with an absurd high learning curve. Got software that’s buggy and has security issues? You can safely bet it’s coded in C++.
> Got software that’s buggy and has security issues?
> You can safely bet it’s coded in C++.
Hrm, that’s funny…
Strange how the app I was working on (in C++ using hand written libraries) that communicated with an app somebody else was working on (C# using all of the power of the .NET framework & its myriad of library calls) was much faster and never crashed, yet their C# version was poky, slow, unusable, and crashed frequently, especially when the data flow got heavy.
C++ is buggy indeed! Or, maybe it’s the programmers! IMO C++ is JUST NOW getting to its prime as a language and has reached a level of maturity that no other can match. Problem is, few bother to learn it and discover its power, and EVEN FEWER have any idea how to write a clear, concise, maintainable program. I haven’t used a raw pointer (except when forced to by other people’s code) in C++ nor have I had to explicitly delete something in ages, yet my programs still have deterministic (and good) performance! (try that .NET!)
In any discussion of programming languages, a distinction must be drawn between the merits of the languages themselves, which can be considered in the abstract, and the concrete nature of the external world. In the real world, the choice of language for a project is much like the choice of language for a book: it often depends little on the merits of the language and much on the particulars of the environment. As such, citing popularity as the reason one programming language is better than another makes no more sense than citing the number of speakers as a the reason why one natural language is better than another.
Now, as for the reason why C++ is so heavily used: inertia. Simply put, everyone uses C++ because everyone else uses C++. This is not due to any particular technical merits of C++, but because of the sequence of historical events that have shaped our present reality. Consider an alternate reality in which the abstract details of the languages remained the same, but the practical realities were different. The OS was written in Lisp (or insert your favorite language here), not C++, so C++ had to suffer the disadvantages of being the non-native language. Everyone knew Lisp, not C++, so Lisp programmers were a dime a dozen and C++ programmers were hard to come by. University courses taught Lisp early, and C++ occasionally or never. Big vendors spent lots of money on creating a variety of good Lisp implementations, not good C++ implementations. Citing Lisp as the implementation language for a project never encountered any management resistance, while management was always skeptical of C++. Lisp development was continually needed because all the big codebases were already in Lisp, not C++. In such a world, everyone would use Lisp, again not for any technical reason, but because everyone else was using Lisp (or again, insert your favorite language here).
There is no particular technical reason why this hypothetical universe is less plausible than the one that actually exists. The real reason why our universe looks the way it does is probably the fact that the technology to really make higher-level languages go fast (powerful type inference, incremental GCs) weren’t really mature until the late 1980s, early 1990’s, and by then C and its direct successor C++ had already become entrenched.
I would call myself fairly C++ knowledgeable and i use it often for user mode programming. But once i had to debug someone else’s code written in C++ and following were my horrors:
1. templates inside templates inside templates….Nested templates are the worst thing designed in C++
2. Operator overloading – While looking at the code, i really did not know whether a + is a function call that can throw or it is a simple addition.
3. Exception handling – It just makes large project so much harder to debug because you never know once an internal function throw, where the exception will get caught. And the handler that catches the exception usually doesn’t have any idea on what to do with it.
4. smart pointer type stuff – C++ doesn’t have garbage collection and people should try to mimic that. With all the auto_ptr crap associated with nested templates, finding where and when an object leaks was a nightmare.
After this C++ experience, i became quite anit-complex-C++. I like some of the features it provides like data abstraction using classes etc but it is becoming increasingly complex.
For myself i only use following C++ features:
1. Basic C features
2. Classes
3. Derived classes with single inheritance or multiple inheritance rarely
4. Well design STL type templates
5. Virtual function where appropriate but not very often
The things i avoid like anything are:
1. Nested Templates (and in general all templates except STL)
2. Exception handling – I hate compiler unwinding the call stack etc. It is so much harder to debug.
3. auto_ptr style memory management – It is never right and when it is wrong, it is nightmare to maintain.
4. Operator overloading – I avoid it mostly but i know for some math related tasks it is nice. Use with caution…don’t overdo it. One person overloaded operator >> for sending data on socket and that is too much for me.
5. Crap stuff like virtual constructor etc etc and all the *extra smart* C++ receipes available in some books.
And yeah, if you really want to know how twisted C++ can be, read Effective C++ series. After reading that i realized how complex C++ can get and how to never get in that trap.
Edited 2007-01-16 02:50
I agree with you. I too never quite grasped what people were whining about with regards to C++ until I had to read someone else’s code. It was horrible. Mind you, they were good programmers and did document things, but their (ab)use of C++ features like what you’ve listed made maintaining that code so much harder.
Worse than reading good C++ code is reading bad C++ code. One of the big problems with C++ is not so much that it has a lot of features, but that its features aren’t particularly orthogonal. There are a lot of cases where there is more than one way to do something, but its not particularly obvious which way is better, so the programmers pick at random and without strong team discipline, everyone will inevitably pick differently.
Even something really basic like passing a string around becomes needlessly complicated. In almost any substantially-sized C++ code base, there will be at least three string representations: char*, std::string, and a custom string class. And of course there is the eternal choice between references and pointers, declaring procedures virtual or non-virtual, declaring base classes virtual or non-virtual, and needless other crap.
And the lack of GC encourages a whole bunch of other brain-damage. Consider something simple like a function that enumerates what plug-ins are available in an application. In a GC’ed language, you stuff the objects into a list, return it, and call it a day. In C++, you can:
– Return std::list, which implies copying every element.
– Return a pointer to a list, and depend on the client to call free().
– Use an iterator pattern, at the cost of turning a single operation into several functions (ie: getStart() and getNext() or something).
– Use a reference-counted data structure, which implies using your own custom reference-counting infrastructure.
– Wrap the data structure in some sort of smart-pointer.
– Have the client allocate the result buffer, and write into it, turning a single operation again into multiple calls.
None of these solutions are obviously right, so C++ code ends up using all of them, in different places. The lack of GC is why you have utterly brain-damaged (from a memory management point of view) interfaces like sysctl, CORBA’s C++ mapping, reference-counted anything, etc.
Edited 2007-01-16 10:43
– Return std::list, which implies copying every element.
– Return a pointer to a list, and depend on the client to call free().
– Use an iterator pattern, at the cost of turning a single operation into several functions (ie: getStart() and getNext() or something).
– Use a reference-counted data structure, which implies using your own custom reference-counting infrastructure.
– Wrap the data structure in some sort of smart-pointer.
– Have the client allocate the result buffer, and write into it, turning a single operation again into multiple calls.
Indeed. This is what Java (or C) programmer will do while trying to use C++.
Those that know avoid all of above stupidity. Best way how to avoid the need of GC is to completely avoid the problem that GC tries to solve so hard – shared ownership.
Mirek
Oh please. I’ve seen every one of those constructs used in real C++ APIs, so by your logic nobody really “knows”.
To avoid the need for GC, you have to avoid both shared ownership and transfer of ownership. This leads to all sorts of contortions in the code, because sharing or transferring ownership is very often the most natural way to express things.
The only way to avoid sharing or transferring ownership of objects in this particular case is to use some sort of enumerate or iterate idiom. Basically, you punt on building the natural data structure for the results just to avoid having to transfer ownership of that data structure. Instead, you shift the burden of doing that onto the client. You also manage to invalidate all the language’s built-in tools for dealing with integral data structures. For example, if we have an API that enumerates pixel formats, I can do the following:
if(member?(“rgba”, enum-pixel-formats()))
// do stuff
If we want to avoid the transfer of ownership, and instead turn this into an iteration, we have to do something like:
itr = get_pixel_format_itr();
while(itr)
if(*itr == “rgba”)
break;
++itr;
// do stuff
Of course, you can then add a pixel-format-supported? call, but then you’re adding special-cases to the API that replicate functionality that could be achieved for free using a language-integral mechanisms.
For example, if we have an API that enumerates pixel formats, I can do the following:
Well, I do following:
if(enum_pixel_format().Find(“rgba”) >= 0)
if pixel formats is global information.
Or perhaps it is information inside some raster encoder, in that case
if(encoder.enum_pixel_format().Find(“rgba”) >= 0)
You are simply solving non-existent problems.
That solution is simply an instance of the first case I posted: return an STL list (or the equivalent). There are two ways to handle this, and both are less optimal than GC. First, you can return a list. This implies copying the list, which in the case of a large list can be inefficient*. Second, you can return a reference to the list. This is dangerous, since if ‘encoder’ in the above example goes out of scope, that reference dangles.
In general, there are lot’s of ways to avoid GC. I listed many of them in my previous post. However, none of them are as general as GC, and each has advantages and disadvantages in specific situations. The net result is that in big C++ code, the memory management discipline gets quite complex. Moreover, since there is no obviously right way to solve any given memory-management problem, in environments with many programmers or the use of many external libraries, many different memory management disciplines end up coexisting in the same codebase. In the end, almost every big C++ project ends up doing some form of GC anyway (ref counting, smart pointers, etc, are all forms of GC, just less transparent and harder to use).
*) This is actually a general problem with the STL, and indeed any C++ code that avoids sharing memory by doing deep copies in the copy constructor.
Second, you can return a reference to the list. This is dangerous, since if ‘encoder’ in the above example goes out of scope, that reference dangles.
Yes, dangling is problem. But GC solves it only partially – “encoder” can be “disposed”, in that case with GC you will have a non-dangling pointer to already dead structure. Can lead to much harder to resolve problems.
BTW, avoiding shared ownership leads to a programming style that effectively avoids dangling pointers too. If things are deterministic, dangling pointers are less likely to happen. (I have no met dangling pointer or reference for a duration of one year or so
And actually, I do agree with you that almost every big C++ project does stupid things to emulate GC. What a pity…
Kills the language reputation.
If you were programming a spaceship to go to Alpha Centauri to pick up some curvaceous space babes which programming language would you select.
Hey, ladies… How’d ya like to ditch this old star system and check out my Python?
I hate “The Problem With…” articles. They’re written by negative people with too much time on their hands. Instead of using that extra time to do something positive, they use it to tear something else down.
Of course C++ isn’t perfect! Duh! But instead of wasting time telling other people not to use it, go write some code in a different language instead. Like imperfect Java, or imperfect Python, or imperfect C#, etc, etc, &c.
I would call myself fairly C++ knowledgeable and i use it often for user mode programming. But once i had to debug someone else’s code written in C++ and following were my horrors:
1. templates inside templates inside templates….Nested templates are the worst thing designed in C++
2. Operator overloading – While looking at the code, i really did not know whether a + is a function call that can throw or it is a simple addition.
3. Exception handling – It just makes large project so much harder to debug because you never know once an internal function throw, where the exception will get caught. And the handler that catches the exception usually doesn’t have any idea on what to do with it.
4. smart pointer type stuff – C++ doesn’t have garbage collection and people should try to mimic that. With all the auto_ptr crap associated with nested templates, finding where and when an object leaks was a nightmare.
After this C++ experience, i became quite anit-complex-C++. I like some of the features it provides like data abstraction using classes etc but it is becoming increasingly complex.
For myself i only use following C++ features:
1. Basic C features
2. Classes
3. Derived classes with single inheritance or multiple inheritance rarely
4. Well design STL type templates
5. Virtual function where appropriate but not very often
The things i avoid like anything are:
1. Nested Templates (and in general all templates except STL)
2. Exception handling – I hate compiler unwinding the call stack etc. It is so much harder to debug.
3. auto_ptr style memory management – It is never right and when it is wrong, it is nightmare to maintain.
4. Operator overloading – I avoid it mostly but i know for some math related tasks it is nice. Use with caution…don’t overdo it. One person overloaded operator >> for sending data on socket and that is too much for me.
5. Crap stuff like virtual constructor etc etc and all the *extra smart* C++ receipes available in some books.
And yeah, if you really want to know how twisted C++ can be, read Effective C++ series. After reading that i realized how complex C++ can get and how to never get in that trap.
Was it really necessary to post that twice?
Quite from the article:
But when was the last time you used C++ to write a line of business app or website?
Business app 20 minutes ago, website yesterday
Seriously, C++ is the most misunderstand language. People simply do not know how to use it right and do stupid things with it – and that unfortunately includes most so called “C++ experts”.
Seriously, C++ is the most misunderstand language. People simply do not know how to use it right and do stupid things with it – and that unfortunately includes most so called “C++ experts”.
A language that easy to misunderstand and abuse is a bad language.
One way to look at C++ is to note that the signal to noise ratio is too low. While it is true that you can “write Fortran in any language”, some languages make it too easy to do so, and C++ is one of those.
For every “right” way to do something in C++, there are three “wrong” ways.
Almost every feature of the language is easier to abuse than to use properly.
I don’t want to have to fight the language in order to write good code in it, and more than any other language I’ve ever used, C++ is a battle.
Seriously, C++ is the most misunderstand language. People simply do not know how to use it right and do stupid things with it…
That’s exactly the problem with it–it’s entirely too easy to do stupid things with it.
In my last job, I worked on a big C++ project with about 10 other developers. I spent a lot of time unwinding and figuring out bad code. I came to the conclusion that all of that capability just gives less-than-excellent coders more power to obfuscate.
C++ is propably the worst Programming Lanugage ever. I prefer to use it for my most important projects. I apply the same method as CrazyDude0.