Are You Working Too Hard as A C++ Developer?

There is probably a multitude of ways that you can work too hard as a C++ developer, but there are two specific ones that I would like to focus on:

  1. Reinventing the Wheel
  2. Using C++ Where It Shouldn't Be Used

Reinventing the Wheel

Most C++ developers I have encountered seem bent on reinventing the wheel instead of building off of the work of others. Building code in house can be very gratifying. You have the thrill of building from scratch and the knowledge of full control. Building from scratch also means taking on huge time and cost risk for debugging and maintaining code, a price that has often been paid already by others. For most any difficult feature or data structure that you need to implement, you should ask yourself three questions:

  1. Does this feature already exist in the standard library?
  2. Part of the fact that nobody understands C++ is that nobody understands the C++ standard library (also referred to as the STL). There are several good references for the library, such as SGI's. My personal favorite is still C++ in a Nutshell.

  3. Is it in Boost?
  4. Yes, Boost is big. Yes, it can be a pain to add it to your application. However, the license is very free (MIT-like), and it contains an amazing amount of resources. We have covered boost several times in the past here.

  5. Has Anyone Else Done It?
  6. A virtual cornucopia of C++ libraries exist out there. Few of them are as well reviewed and designed as Boost. Google Code, Freshmeat and Sourceforge are all great resources for finding open source projects which might already meet your needs. There are many software licenses which may conflict with your personal interests, so do be careful when choosing a code base to use.

Using C++ Where It Shouldn't Be Used

C++ isn't the perfect language for every situation. It is a very versatile language, but sometimes other languages are better suited to the task at hand.

A method that may work well for your project:

  1. C++
  2. All of the back-end library and systems level code and anywhere performance is a concern.

  3. Lua
  4. Runtime configuration and scripting of your application. Also, using Lua as a possible way to extend functionality at runtime.

  5. Perl/Python/C#/Java/Javascript
  6. Scripting language of your choice should be used for the user interface.

SWIG can be used as the glue to pull the pieces together. Dynamic languages and scripting languages provide for faster prototyping and building of user interfaces than C++, on average.

Comments

GUI Framework

Hello Jason,

What GUI framework/s do you utilize for your projects?

Thanks,
Mark

GUI Frameworks

Most of the GUI frameworks I have used are C++ based: QT/gtkmm/wxWidgets. Part of the problem that I do not mention above is there is a bit of a bootstrapping effort to get SWIG up and working well with your C++ back end.

So, if you are trying to bang out a quick prototype, sticking in one language may be your best bet. gtkmm is the easiest to use C++ GUI library I have used (and the best designed, in the crossplatform arena anyhow).

I have used this technique to build a C# based UI on top of a C++ back end. Which did make for pretty quick UI developing. That is one thing that Visual Studio is good at.

I have not actually tried this myself, but it seems that picking some language, Lua, Python, Perl, something that is good at rapid prototyping to build up your prototype with would make sense, that avoids the "working too hard" point of this article. Then, as you begin to fully understand the problem you are trying to solve, come back and replace the core functionality with a C++ library, gaining you the benefits of C++'s performance and C++'s type safety.

I guess that's some rambling thoughts... anyone else have ideas to add?

-Jason