What’s wrong with C++
…from the point of view of someone that actually uses it? The bits from my last post haven’t even dried up yet, and another fascinating rant about C++ has popped up, this time from Zed Shaw.
What’s interesting about these rants is that the ranter isn’t really using C++. They’re C hackers, or they program mostly in Python, or they used C++ at the beginning of the 90s. So I thought it would be interesting to write about my experience with C++.
First, a little background info…
I started learning C++ about 10 years ago, first the C part and then the ++ part. Nothing serious, just toying around with small projects to learn and have fun. I didn’t use it professionally until about four and a half years ago, when I started working on a large scale C++ project. Since then I’ve used it almost daily.
Two and a half years ago I came across Qt almost by accident: the large scale project that I was working on was being ported to Linux and the port was enabled by Qt. Since then, I’ve used Qt almost daily too.
Right now I’m working on a Qt C++ project that’s about 25KLOC in size and growing. It’s a multi-platform, threaded client-server and it’s a line of bussiness app if you’d believe it. Working on it is fun, and I’m glad that I picked Qt and C++.
Okay, enough with the history, what about C++ and its warts?
Issues that bother me in practice
- Compile times and the include dependency specification: this is a problem that every C++ programmer will have sooner or later. It can be delayed and mitigated with a good physical design, precompiled headers and distributed compilers/linkers, but it can’t be solved without throwing away compatibility to existing code completely.
- The small standard library: not a big issue in itself, since you can find other libraries for anything you might want to do, but it’s unpleasant to install all those libraries and make sure that they work together nicely. Using more libraries instead of a large standard library also means that you have to wait on each library vendor to port the library to different OSes/compilers, upgrade it and so on.
- lack of reflection: I like Qt’s moc and I miss it in standard C++. I also wish it had more features.
- lack of type inference: even with typedefs I’m typing more than I have to. C++0x will thankfully fix this.
- localization & internationalization support in the standard library: the implementation is complicated and difficult to use. After browsing through C++ IOstreams and locales I’ve decided to just use Qt and not worry about it.
- template error messages: they’re long and hard to understand. I usually parse a template error message in about 10-20 seconds depending on the difficulty. The worst offenders are metaprogramming-heavy libraries such as Boost Spirit. In that case, I try to analyze the code first and see what might be wrong. STLFilt can help.
- functional programming support: this will get better in C++0x, but I can’t use C++0x now, at least not on all platforms and with the other libraries I’m using. Functors and free functions are cumbersome to use with algorithms.
- tools and parsing: C++ has access to solid, mature tools, but those tools are much harder to develop than for other languages and generally don’t have as many features.
Issues that don’t bother me at all, but are regularly brought up in rants
- memory management: never a problem for me. The last time I’ve had a memory leak was about two years ago and it got caught at code review. C++ has good support for memory management and good tools that can be used for runtime debugging. It might as well have GC, I wouldn’t be able to tell the difference.
- memory corruption: memory corruption can be both exciting and scary. Exciting because you have to go down to the memory address level and do some sleuthing, scary because it can take days or weeks to find some bugs. I usually don’t sweat these bugs, they were very rare in the code I’ve worked on, and when they occurred they were easily found. e.g: the last one I’ve solved in maybe 30 seconds, the tools have gotten very good. The worst I’ve encountered was a problem with an embedded STL in a large project that took a week to figure out and only because of my lack of experience at that time. Some people love debugging.
- multi-threading: it is hard in most languages. The trick is using higher-level libraries such as QtConcurrent, Intel’s TBB or OpenMP. Sure, if you’re doing PThreads it’s going to be painful.
- string formatting and string support: I generally don’t use iostreams or std::string, but when I did I found them acceptable. Unicode support was the biggest issue, but “there’s a applib for that”. Now I use Qt’s strings and streams; they’re as easy to use as Python as far as I’m concerned. Don’t want Qt? Use boost::format or any other of the nice formatting libraries.
- templates in general: I use them when needed to break dependencies, write generic code, etc. I try to keep template code manageable, without going into the metaprogramming stuff; they are one of my favourite C++ features.
- exception rules: I don’t see any problem with exceptions in C++ as long as you’re using RAII. Other languages (e.g.: Python) use them extensively for error handling.
- STL & Boost: I’ve used both for a lot of time and I find them very useful. Contrary to popular belief, most templates don’t use metaprogramming techniques. You don’t have to install Boost, it’s mostly headers. A large part of Boost became TR1 so it should even ship with your compiler now.
- const: This one came from Zed, I don’t think I’ve seen that many people complain about const. Personally, I constify everything that I can, even const type* const.
- everybody learns a different 10% of C++: strange, because I use all of it and always have. It’s not that hard either, I’m not a genius… Sane projects have coding guidelines and architectural documents. If your teammate can waltz right in with a template metaprogram or is generally macro-happy and it doesn’t raise eyebrows at code review, you have bigger problems than using C++. I’ve had to fix two C++ projects so far; my only job was to do what it takes to make the programs work and ship them to the customer. Most problems were memory leaks, superfluous use of casts, functions that didn’t compile on all platforms and so on. Fixable. What I couldn’t fix – and had to patch up as best as possible – were issues with the program logic and architecture. Those were not caused by C++.
Ok, but what about…
You probably have your favourite C++ misfeatures. Odds are that they don’t matter than much in practice, or workarounds are available. Maybe I just got used to them and consider them a C++ tax.
Comments are closed.
I programmed professionally in C++ for over ten years. At the time I loved the language and was seriously proficient in it. When I finally switched to C#, I initially missed a lot of what C++ offered, but I got over it and now use C# for many things.
In the work I did, I needed reflection so much that I actually wrote a library and system that implemented reflection on top of C++ in 1992. I think that people don’t appreciate enough what reflection (lightly used) can accomplish for you in certain circumstances. In particular, reflection allows for a much abbreviated approach to unit testing with tools like NUnit that rely on reflection heavily.
-Kelly
Really interesting thread.
I have the deepest respect for people that have the experience and knowledge needed to handle a complex subject like C++. After 10 or so game productions in C++, I still regard the language way to cumbersome to produce stable and maintainable code in. These days I simply try to avoid C++ projects, since I feel more productive in other languages (here are some reasons that I mostly agree on: http://www.fairyengine.com/articles/cppvscsharp.htm). Another important point is that C++ seems to fall behind on the tools side, that is, when compared with the amount of tools available to backup a JAVA or C# production.
When you really have to go the C++ route, then a problem I have experienced is when a complex subject – like C++ or multi-threading – is not regarded complex by the team members. The “I am such a brilliant coder” attitude doesn’t really cut it, when the team needs an “I really need to focus on learning the C++ language” attitude. Synchronize the team and learn from the best e.g. read Effective C++ and discuss what other readers think (e.g. http://www.vterrain.org/Implementation/effective.html).
NOTHING is wrong with C++
to me, reflection is another antithesis of object oriented programming … similar to “properties” (C# exposing your private parts to the public)…
asking the question “what type are you” IMHO, violates the notion of polymorphism and the ability to dynamically alter the code behavior by NOT having to ask “what type am I/are you?”
do these features cause the very same spaghetti code in C cause by bad software engineers (not the language’s fault).
OK, to tell you how much i loved C++, i wouldn’t want to program on anything that isn’t Borland. Since so many languages came out after C++, I went back to assembly for microcontrollers and linux for console C++ programs. I think it is the best language I could think of even now. I hate MFC. Long live to the Main() function.
Finally managed to approve all comments. Yes, even the cowbell one.
I must say that even though I try to read most news and discussions about C++ – from lambda the ultimate to blog posts – I’m impressed with these comments. Industry veterans, newbies, lovers, haters have all posted…
Some quick thoughts:
* I did program in C# and Python. Generally I use Python in interactive mode to explore/do prototypes. PyQt is great.
C# is a language that I could use instead of C++ for most things, but the funny thing is that I don’t need to. C++ works for me, so I keep C# as a backup.
* At this point I’m more interested in architecture/domain knowledge/customer interaction than languages. I am familiar with D, haskell, Ruby and the ideas behind them, but I just don’t think that using any of those languages will give a productivity boost over C++ and Python.
* For my current project we picked native over web due to skillset and requirements. Part of the app will
probably be served on the net when needed. Personally, I’m a fan of native, but I will use webapps when it makes sense.
How you guys compare QT with WT?
Admission: I don’t write C/C++ anymore, though I still port code for projects when something open source can assist a project. I started around 1988 and mostly stopped in 2004.
I don’t miss subtle stack overwrites, you know, just a few params get trashed and when you add debug, it doesn’t happen, because it’s packed differently compared to the stripped production version!
I don’t miss large product porting, as some coders over the years were still novice and didn’t know to use endian handling libraries!
I don’t miss having to mix / fix BSD versus SYSV versus POSIX libraries (I make no mention of all the #ifdef win stuff). Nor learning new teams’ great library X. Old teams’ great library Y was just so very different. Seems every successful product has a complex mix of old code, and C/C++ often has some serious baggage.
I still like C. I prefer to pass pointers to functions and chains of objects than do OOP. Both ways seem to have serious amounts of debug time, with bigger code bases, in C/C++!
I still don’t like that C++ OOP gets big, and complicated, fast. By 2 million LOC contributed to by a team, C++ gets darned incomprehensible (for my small brain). Biggest I’ve worked on was 5 million LOC (weather forecasting product).
I was around for the introduction of Structured programming (anyone do Jackson at college?) That was to defeat the spaghetti code that was around from before its general acceptance
before I go, just a thought. Not my own, so I’ll say that I quote Rich Hickey – “mutable objects are the new spaghetti code”
Hmmm, is it only me here thinking that higher level languages (something say without the likes of C inside) are the way to go!?
regards
Alex
code monkey and wordsmith at Lexecorp.com
Hi
I’m not agree with your arguments as drawbacks of C++ (or further C++0X) language.
Plus some of those arguments sounds partially or totally wrong to me.
Finally please consider the most arguments you seems to advance are absolutely not related to the language fundamentals but to third party libraries, operating system, compilers, etc …
New programmer people are now very greedy with “easy to use” languages but – in my opinion – those languages are really not good at all for shaping their programmer skills in terms of understanding what happens at hardware level behind your thousand lines of “easy code”.
Regards
For me C/C++ means speed which i believe no other languages can ever provide. If you don’t like C/C++ you don’t know to use it.
There are good reasons not using mm/gc based languages:
How long takes one gc run with allocated 200GB RAM?
PUSH ALL
For those that note that C++ can be hard to read. I’ve found plenty of C code since the 1980s, that required a caffiene binge and a steady stream of cussing to work through.
It’s my experience that you can write crap code in any language.
There is no reason why C++ cannot be elegant. I think that as you move to languages that have a larger poputlaion of programs, you’re going to see a wider variety of coding styles and levels. C has become a niche market and the coders left in it, have likely all honed their craft well.
I will say though, that assembler beats C for elegance, and machine code is the lagnuage of the silicon gods. :P
POP ALL
I also agree with Alex Turner, but I think it is not the language that makes it hard to work in teams with people with largely different knowledge.
Of course some languages are easier to grasp than others, especially if they contain some less common programming paradigms. I can not avoid thinking that not C++ is the problem but rather object orientation, which is at best confusing, if improper applied. Declaring a multitude of classes, deriving from each other, forces you to grasp the behaviour and variance of all those classes, if you want to understand how some application works. And you seldom find any rational documented in code or elsewhere describing the why something was designed the way it is. You are lucky if the api of the classes is completely and correct describes. You are near heaven, if the same api is fully tested. And get it right, every method and member variable you can access, either directly or in an derived class, is some sort of api.
One thing, that may make C++ harder than other languages like Java, might be the fact that it provides powerful and complex features like templates whose intention must be fully understood to apply them properly. I learned: If in doubt, don’t use the feature. If you must use it anyway, understand as much as possible about it. But this is not only true for language features but also for algorithms, design patters, libraries, tools and everything else involved in software development.
Some people says that C++ is old and complicated language, but can’t be more wrong because it’s a really fast language, not like graph on java or C#, nothing about run-time machines, it´s direct to processor comunication, fast and easy.
As last comment, I Agree with the guy that says that C++ is not for lassy people, I invite them to study and test a really fast language.
PD. I have tested C, C++, java JDK 1,3->1.6, C#, phyton, VBasic, VBasic.net, I keept with C++ when I can.
Well,
I’ve experienced none of those problems as quoted.CPP lets you go close to the hardware. This makes it both Powerfull and Dangerous. I always try to limit the number of Base Classes, so that indeed, a new developer has only to trace back a few steps to find underlying functionality. There was an idea in the 1980’s of derriving a new class for every trivial extension. This makes for Tons of Documentation to read.
Alternatively, We add most extentions to the Base Class, Derive a Class which initialises Some Properties, and then use Asserts to ensure that the correct derived class is invoked.
Derivation of classes is usefull for Framework Developers.The MFC Framework wizards stand out as examples of this!
It is on rare occasions indeed that we ourselves derrive classes from others.
Microsoft does much the same in MFC! Most of the CDialog facility is for instance implemented in the Base Class of CWnd.
No, I Like CPP, and have nothing against it.
Regards,
Bram van Kampen.
Yea every language has its problems and the technologies are evolved over time. People are preferring .NET technologies in these days. Even it’s productive, we’re paying for performance. Also .NET versions are not really compatible each other. The CTS is too huge and there’s steap learning curve for the proper usage of the classes and libraries available. Also people are not really bothered about the basics of computer science. Everything built-in place. A good designed C++ program will not face much issues with memory management and corruption. If too many problems are happening, it’s not the right technology to use within the context. Choose something else!
Good article – interesting to see how Qt has smoothed the platform and localization issues.
My only issue has been getting the right people – design and coding practices being the biggest problem.
I can see why other languages (namely Java / C# ) are very popular for new projects especially when coupled with accessible design patterns implementations.