Joe Pruit posted a blog responding to some thoughts from Rogue Wave on C++ in 2008. We know that not everybody sees C++ in the same way we do, but we issued the press release was to challenge some of the conventions of how developers and architects perceive C++. Joe’s comments are worth reading, and are also worth responding to.

Enterprise applications do widely use Java and .NET, no question. Managed languages are the right tool for the job for a wide variety of applications. C++ however, (plus C and other native languages) continues a solid, and in many cases, growing presence in several areas:

High performance: for applications that require low latency and/or low memory usage, a large number of architects are choosing C++ in favor of managed languages. These are common in Financial Services, Military and many other applications. An interesting recent example is the team from Carnegie Mellon that won $2mm in the DARPA Urban Challenge for building an intelligent robotic car. According to the project lead, “Everything we did was written in C++.”

Embedded: For embedded and mobile devices, one of the fastest growing areas in computing, C++ is the language of choice over both Java and .NET. Lower memory, tighter power and heat limits and other requirements make C++ a natural choice for optimized application development. According to the Gartner Dataquest report ‘User Survey Analysis: Embedded Software Development Tools and RTOS, North America, 2006′, “For application development, C and C++ are the most popular development languages. Surprisingly, Java usage dropped in 2006.” (Daya Nadamuni, 13 September 2008)

Existing apps: And, of course there are billions of lines of existing mission critical applications built on C++ in enterprises around the world.

These are almost all mission critical, and many are also legacy. In my experience, many if not most mission critical applications are also legacy. My favorite quote on this: years ago, one of my dev managers once quipped that the definition of legacy is “anything that has gone into production…”

As far as the overall viability of the language, there are a few interesting points worth considering:

1. C++ developers are commanding strong salaries, in many cases higher than developers with Java and .NET. I don’t know for sure, but I suspect it’s a combination of C++ resurgence and a smaller number of C++ developers available.

2. Universities are starting to reconsider their move to teaching computer science students in Java. Many universities continue to teach in C++ so that students have a solid foundational understanding of how systems work. Some professors contend that teaching Java has contributed to a decline in computer science skills.

3. The language has a vibrant (and broad) standards community and continues a solid evolution. The C++0X standards effort is creating the next version of the language. The proposed enhancements include modern concepts from Java and elsewhere, but still maintain what makes C++ unique and different.

Although Java and .NET continue to have significant mindshare for mainstream applications, C++ is the language of choice for many architects in new development projects - probably more than most people think.

It appears as if the latest way to find more processing power is heading into the mainstream. Both Nivida and AMD have GPU cards dedicated to processing instead of graphics. The popular book series GPU Gems has even released a third generation of the series that contains quite a bit of information and examples using the CUDA architecture. However, if you’ve looked at CUDA you may have had a Bud Light commercial moment like I did and said, “Dude…”. The years of not writing code may be skewing my view on it, but to me this is not a simple API. It seems that without easier to use higher level tools, GPU processing might be restricted to the uber-brains of software engineering that do matrix math in their head for fun. Now I don’t want to single out CUDA, because Brook doesn’t seem likely to win any Easy Button awards either.

What is clearly needed is an abstract API on top of both vendor cards, that lets C++ developers write code without a huge learning curve. That’s an easy statement to make, but a lot of complexities arise. I have been asking some of our customers about what they think an API like this should look like, what level of complexity to hide and not hide, etc. While there is some consensus, there is also just as much differing opinion. The only obvious answer seems to be that people want to take advantage of GPUs, and they’re looking for a way to make it easier for them to do so. If you have strong feelings on what you would like to see, please let them be known.

It was our second year participating in the OOP conference in Munich last week.  This conference focuses on aspects of modern software engineering, so as you can imagine, it is heavily infused with SOA technologies.  I gave two talks, one about modernizing C++ applications, and the other on creating a service grid.  In my talks I focused on the challenges of maintaining performance characteristics when moving from a monolithic application to an SOA, while also dealing with distributed computing issues that may not have been previously relevant.  Both drew a good number of people and several of them came by our booth later to discuss their situation and how it would fit in with what I discussed. 

I was a bit surprised that there were a good number of people that said they have problems dealing with large XML files.  We call this VLM (Very Large Messaging) and we are very familiar with the issues surrounding it.  The most common issue has to do with memory consumption.  Typical DOM based parsers use about 6 times the size of the original XML file in memory.  When you start dealing with large files, that quickly becomes a problem.  The other main issue people are having is rooted in performance.  Parsing large files is time consuming, especially when unexpected things like garbage collection kick in.  We have been solving this problem for a while now with our HydraSDO for XML product.  It’s very fast being written in C++, provides a native Java API as well that utilizes shared memory so as not to impact performance, and uses a non-extractive, indexed parsing model that gives a 1.5 times original XML document size memory footprint. 

I’m excited for the opportunity to help these people with the large XML file problems they’re having.  If you’re having similar issues, let me know and we can get you some quick help.