C++ Generic Coding vs. Java Frameworks

As an ardent C++ developer, I’m often traumatized by the amount of potentially useful software infrastructure that simply doesn't exist. When working in Java there are multitudes of frameworks and reusable libraries that allow many problems to be solved at high levels of abstraction without reference to the underlying …

[Alan Mellor]

Tricky to make it quite as useable

One nice Java feature that helps out framework users is reflection, whereby Java code can find out the names and types of methods and fields in a class. As a framework user, this enables a variety of 'automagic' things to be done, without the need for manual configuration.

C++ doesn't have this feature. This tends to make the usage patterns of frameworks like Hibernate in C++ that little bit more tedious.

But it sure would be nice to get even a reasonable open source Object/Relational mapper in standard C++ ...

[Malcolm Melville]

Tasking models

Java Frameworks often win because they offer a tasking model generic to the language. Something C++ has always shied away from. Having worked extensively in both languages, one of the biggest issues I have faced has always been how to ensure a portable tasking layer for C++. There are solutions out there. The lack of a standard though means that solutions to a lot of real world problems either mean you have to roll your own abstraction layers for tasking, or depend on someone elses. And some solutions are simply incompatible. Will be interested to read others take on this one and whether this is covered in later articles.

[Torben Mogensen]

C++ vs. Java: Memory management

I think one reason we see fewer tools for XML processing etc. for C++ as opposed to Java is that Java offers automatic memory management (I.e., garbage collection) where C++ does not (as a standard, though tools exist). Managing tree structures like XML is so much easier when you don't have to worry about when subtrees are no longer reachable, as the run-time system will do that for you.

Also, some tools for Java exploit reflection, which is not available in C++. But, in my opinion, the need for reflection is a sign of missing abstraction mechanisms and may be reduced with the introduction of generic types in the latest Java versions, though a type class system like that of Haskell would reduce the need even further -- in my experience, Haskell programmers use type classes for many of the things Java programmers use reflection, i.e., generic marshalling/unmarshalling, unit test generation, etc.

[Stephen Booth]

Relative Performance

Part of the difference is just that Java has colonised the SQL/XML space so effectively that new projects that require this naturally gravitate to Java. I don't think that the performance difference between C++ and Java is really significant enough to motivate the switch to C++ by itself.

I've done quite a bit of performance comparisons between the two languages and with a good JIT I find the variation in performance due to different programming styles much greater than any inherent speed difference between the languages.

I also feel that because the core Java syntax is much less rich than C++ (not that I mind) there is often only one way to approach a problem in Java where C++ gives you a choice of four or five. In a perverse way this makes code re-use more likely.

[Anonymous Coward]

Java and C++

Java vs C++... Again...

It seems to me that Java was designed by Sun to allow a large number of people to churn out code that is needed for enterprise applications. While this sounds great, it has some caveats. Most notably, it's relatively simple for _anyone_ to write an application doing something that traditionally would have been difficult and time consuming. Where's the caveat? It's too easy! Kids right out of school assume that because they can write code that will "do the job", they are writting the right code. Let me exemplify what I mean. At the company that I work, we do both Java and C++ and normally whenever we've interviewed new graduates, they all have "Java experience" and almost no C++ experience. Still when asked about why in Java 1.4 a vector is slower than it need be for native types (I know! But although we don't sell our software as such, the truth is that it qualifies as scientific computing and visualization, running on 3 different hardware/OS platforms, so performance is _always_ an issue), they don't even know what we mean. Further still when we start asking Java programmers about how to do things faster and more efficiently, all they know is how to do it more easily; not exactly what we were asking. Is it that they are not properly taught? Not likely; I honestly believe that each language molds the brain of the people that use it. Among other things, Java is about ease of writting code and portability; C++ is more about performance and portability (except perhaps some poor souls trapped in MS extensions). Java presumes that all computers have enough memory and enough processing power to do whatever you want; C++ remembers that no matter how much memory and processing power you have, you will never have enough (ask the folks at Folding@Home) because there is always a problem that you would not have dreamed of solving 5 years ago, but now, it sounds almost possible. The question is: Where do you stand? Everyday problems for which we have enough power already or on the edge of what can almost be done? Neither place is "better". I'm sure that there is more people standing in one of them than the other. Both are necessary.

One final anecdote. Just for the heck of it, one guy at the office and I decided to implement certain geometric algorithm. He did it in Java, I did it in C++. At first my code was running maybe 50 times faster than his. We were both very surprised. We expected a difference, but not so much. He got to work into making his implementation faster, and in less than two days, the Java version was performing only about 4 to 5 times slower (yes, we benchmarked so that the JVM load times were not included in the run time), and he felt that there was very little else that he could do to make it go faster. Now, this is not one of those postings where people just scream: "See! C++ is faster!" That is not the point. The point is this: His very first version had much less code than my C++ version and looked very much like a typical Java program. Every time that he rewrote the code to make it faster, it looked more and more like C++ code would have. What did we learn from the excercise? From the start, he wrote proper Java, simple and short. From the start, I wrote proper C++, fast specialized code. What is better? Depends on what you do. At the time, whe wrote development tools for others in the company; simple and short code is better for maintainability than fast and "complicated". I write the code that goes into one of the optimization engines that the company sells; faster code is a must and we're willing to spend more time maintaining it because being faster than the competition is very important in our field.

What does this have to do with the article? :) This: Java is probably being use to tackle, over and over, the same set of problems that are not extremely runtime critical, while C++ is being used to code things where runtime is viewed as being more important, and so, we tend to write specialized code that will give us that extra bit of performance. Is this how it should be? I don't know, but I think that this is what happens.

[David Norfolk]

faster Java

Is BEA's JRockit a valid response to Java performance problems, if there are any such?

[Matt Day]

Sun Owns Java

One of the reasons I think Java has all this nice framework is that Sun owns the entire specification. It's trivial for them to add in an XML parser that works everywhere and everyone can use because it's bundled. Things like the collections framework and the sax stuff is all built-in.

C++ has a different history, where is was originally just a parser which converted C++ code back in to C and compiled it this way. Some compilers, such as the HP compiler are still based on this early model. To them, ideas like Generics and so on are relatively poorly supported and items like the standard template library (STL) are "new" ideas.

While Java was designed to have all these features, different C++ implementations added their own. It wasn't until later that standardised features allowing vectors and so on were added and widely supported across platforms.

Also, a lot of applications where C++ is 'good' at is based on getting to the hardware: Games (OpenGL), Operating System front-ends, Web Browsers and so on. These don't need abstract access to remote data or a way of describing it. They need byte-for-byte optimisation to get that rendering speed up or the load times down. Your average business expensing tool or whatever, however, isn't so reliant on speed but needs to be portable and simple to maintain. In this case, Java is perfect... Define the database schema loosley, build up a solid GUI interface and then link it in to the backend du jour.

Finally, as a C++ programmer with a lot of Java experience, there's no way I'd compare the languages. I write projects in both languages and it's always a clear decsision at design-time which language will be used. Rarely have I thought "Wow, this could be written in either." -- it really depends on what the application needs to do.

[Dave Minter]

Bootstrapping

Take a look at the internals of Hibernate and you'll see that they rely on a very substantial number of additional libraries.

It's not driven by the availability of more comprehensive standardisation efforts, since Hibernate was entirely unblessed by any standard (on the contrary, it has inspired many of the new features of the EJB3 specification).

No, framework creation is a bootstrapping problem. Sun made an incredibly good call when they made the *standard* J2SE class library so vast. With such a bulk of basic functionality already provided for you, it's easy to build upon it. The first generation of tools, bells, and gizmos, were basic library additions (log4j, dom4j and the like) - and these made extensive use of the standard libraries. They also provided an obvious starting point for future standardisation efforts.

With these gaps filled and de facto standard libraries added to the actual standard ones, it became practical to build substantial frameworks without having to reinvent a dozen new types of wheel in the process.

This ecosystem is what was missing - no substantial universally available set of library functionality for C++ existed. Instead dozens of platform specific or commercially restricted packages became available.

The creator of a new C++ framework must either roll together all of the basic functionality from scratch, or necessarily restrict the available audience to those who are able or prepared to accept their preferred subset of libraries.

Which is why I'm an ex C++ programmer, and a current Java developer.

[Connor Garvey]

Exception handling and checking

There are two reasons I prefer programming in Java. I'd argue that they are two of the reasons that so many libraries exist for Java. People like the language.

First, Java programmers use English when writing their code. I find no end to the frustration I experience when I have to read C++ code that looks like "obLIU->fnm = infnm;". What do those variables mean? I have to trace back in the code and try to reverse engineer their purpose because some programmer was lazy or thought these short names would make the code simpler. Really, it resulted in less legible, more complex code. Any updates to this type of code are likely to contain errors. The person writing the update may not notice that a variable he needs has already been declared. He just doesn't know it because he can't read it. If someone wants to reuse the code, she'll have to try to decipher the author's confusing names. Most Java programs I've seen look more like "loggedInUser.setFirstName(inputFirstName);". That's easier to read and understand, which results in more updatability reuse-ability.

Enterprise applications are also much simpler to write in Java because of exception checking. I know that if a database error can occur in a section of my code, I'll be notified. If I'm trying to open a file and I forget to handle a permissions error, I'll be told at compile time. Java programmers can be much more comfortable in calling their applications "production ready" because they know they've handled these possibilities.

[Kurt Guntheroth]

Java = C++ - performance

Perhaps there are more frameworks for Java because Java programmers need more handholding. (Begging the lightning to strike).

The reason C++ has survived for 25 years (!) is performance. C++ does all the heavy lifting jobs which cannot afford the overhead of garbage collection, interpretation, etc. In these environments, it's likely that the developers have chosen to hand-tune their app rather than rely on a mostly-good-enough third-party framework.

Java works well on non-performance-critical apps. It's conceptually smaller than C++, and the learning curve is shorter. So Java gets taught in colleges and trade schools, and picked up by web developers with even less formal training than that. It takes too long to get good at C++, because there's so much to master.

While there are some extremely impressive Java programmers, there are also a great number of Java coders of, shall we say, modest skill. Many are inexperienced and less well trained. Java performance will suck forever. There's less penalty for the inefficiencies of a framework. The Java ecosystem probably has stratified more than the C++ ecosystem did, with the top tier of Java geeks writing frameworks, and the lower tier using them.

Many C++ frameworks are little elegant things (like STL). There are, however, some bigger C++ frameworks, like MFC. Tell me there is any Java framework with as many projects written for it.

[Niall Douglas]

C++ leads, Java follows

If you look at the history of both languages, C++ tends to innovate while Java clones from C++. This happens because like with C, people tend to push the language far beyond what it was ever supposed to do by deliberately misusing features. This happens, quite simply, because the very best programmers like C (and C++).

The very best programmers do not like Java and therefore have little reason to play with it when there are far more fun interpreted languages out there like Python. There is a reason why Java is taught in most uni courses, and in my opinion it's because of the average mediocrety of the average compsci lecturer (after all, with how little UK academics earn, if they were any better they'd be in industry). They may claim it's because it's 'purer' and better for teaching best practice, but then the average compsci graduate is so awful that substantial unlearning must be invested in them over YEARS before they're actually useful. I know of quite a few companies who only hire non-compsci graduates as then they can save on unlearning costs.

Now there's nothing wrong with cloning from the leader of the pack - it means you tend to get it right first time unlike the leader which will usually get it wrong. No one would claim that metaprogramming in C++ has been implemented at all well, but then no one actually ever intended to implement it originally - it only came about from the best of the best kinda stumbling on it mainly through entirely unintended consequences of the language design. I personally think this is just brilliant, and it's great a real world computer language can permit such innovation given the standard was set in stone so long ago.

But because of such a different development ethos, it does cement each language - C++ continues to get new things done with an unchanged design each day, while Java's design sorta lumbers onwards as something good enough for ordinary requirements and safe enough to let mediocre programmers touch without wrecking your entire project. They're two very different beasts.

By the way, Hibernate (as far as I understand it) can be easily enough implemented in C++. My own C++ portability toolkit TnFOX implements automatic SQL<=>C++ reflection - you can load and store C++ object instances as though they were native SQL types. The default implementation requires the type serialisation semantics to be known at compile time, but it is very easily extended to run off a run-time database (and indeed one of its client projects, Tn, does just that). You can see for yourself at http://tnfox.sourceforge.net/TnFOX-0.86/html/, just choose 'SQL Database Support" from the Modules section on the left or investigate the TestSQLDB source in the test suite. As you'll see, you can bind and use arbitrary C++ types so long as they have an FXStream operator overload declared at compile time (which is the case for most TnFOX types).

[Steve Read]

Choices, choices...

Ah, the old chestnut of C++ vs. Java vs. performance vs. run-anywhere vs. ... Once again, two camps appear: the C++crew and the Javagang, and neither of them is correct, except in part. Both languages have strengths, and weaknesses.

C++ usually runs faster, can be tuned harder even without sacrificing too much portability, and offers great flexibility in how e.g. memory management is done.

Java sacrifices runtime performance for ease of setting up database interfaces, built-in threading, garbage collected memory management, etc.

Tradeoffs abound. We must choose which tool to use, whether the choice is one of language, RDBMS, middleware protocol, GUI toolkit, or whatever. And the winners in this battle are us, the programmers. We have tools that are suited to our purposes wherever they lie on the great map of the software domain, and if we don't have the exact tool we want, we can build it ourselves. C, C++, Java, Ruby, Python, Win32, UNIX, GTK+, Qt, ODBC, JDBC, EJB, STL, Boost, whatever. Each gives us something, and precludes something else. It is up to us to make the choice.

The technical fiddly bits are neither here nor there. In the end, it all comes down to us sitting down and using the squishy things between our ears to do the hard stuff: choosing a route, and designing the platform, vehicle, or whatever that will get us where we want to go.

Isn't it great?

[Frederick C. Lee]

Objective-C: the best of Java & C++ worlds.

Objective-C is object-oriented language: it supports hierarchies of substitutable types, message-passing between objects, and code reuse through inheritance. Objective-C adds these features to the familiar C programming language.

Objective-C is a dynamic language vs C++ is a static language: it differs from C++ by deferring decisions until runtime. Objective-C is safer and more-intuitive than C++ and is the basis of Java's design.

More emphasis should be placed on Objective-C, which can easily wrap around C++ and is closer to the C language than C++. Apple's Cocoa-based GUI is written in Objective-C.

[John Vaudin]

Too 'clever' for its own good

You hit the nail on the head when you say STL and Boost make 'clever use of templates'. C++ designers and developers seem rather too concerned about how 'clever' the technology (and by implication they) are.

I think the comments 'the very best programmers like C' while 'the very best programmers do not like Java' gives us a good insight into the spectacular arrogance of the C++ community.

Truth is cleverness doesn't pay the bills - solving problems does. Java or C# are simply far more productive languages than C++ and that is why they are in the ascendance.

[Niall Douglas]

Not arrogance, artistic flair

Regarding the "spectacular arrogance" of the C++ community, I think this a little unfair! I think it's far more a case of artistic flair - writing in C++ is like having a large range of pastels and paintbrushes to choose from - how low-level you might like an algorithm, which libraries to use, how much you might like to fudge pure OO etc. Conversely, writing in Java is like drawing with a fixed set of crayons - you get a certain range of colours, and you can only draw fairly fixed wide lines. Conversely crayons are non-toxic, while some paints are deadly poisons when misused.

There is far more to implementing a solution to a problem than whether it works or not. If we believed that, all our bridges would look identical, as would buildings. There is also a very important requirement for aesthetics - beauty - and C++ for the most part lets you construct beauty. Whenever I have programmed in Java, I can't say I thought the code as beautiful afterwards - it's a language limitation of not being flexible enough. This was also a problem with Pascal back in the day - it wasn't as beautiful as C. However neither C nor C++ are perfect mediums for expression - I always found LISP to be more beautiful than C, and Haskell has its moments as well.

Many of the 'standard' frameworks for Java tend to have at most two alternative implementations to choose from whereas for almost anything, C++ has half a dozen or more. This tends to mean over the long run that C++ frameworks evolve much quicker through competition and idea cloning. I certainly have found many Java frameworks to be annoyingly designed, clumsy and using inefficient algorithms. If you find that in C++, usually you can choose a different toolkit. In Java, you're generally stuck with what you get and if you need better, you have to go off and reimplement code.

I also disagree with "Java or C# are simply far more productive languages than C++ and that is why they are in the ascendance". A master C++ programmer can always vastly outstrip a master Java programmer's productivity, the problem is that they are far more expensive to employ. The reason for the ascendency is much more an economic issue than technical.

In the end, the other posters are quite right in saying that both have their place and indeed there have been many instances when I have chosen Java for a project. However, I can't say I've ever had as much fun nor satisfaction implementing such projects, and in my mind having fun doing your work is as important as putting bread on the table. Isn't that from where the quality of life is ultimately derived?

[Connor Garvey]

Complexity

C++ does give programmers many brushes with which to paint whereas more recent languages restrict programmers by limiting them to standard frameworks and coding standards. That's why the C's are losing popularity. In these days, processors are measured in terms of giga and terraflops. Memory is measured in gigabytes. We no longer need to worry about tweaking the low-level implementation of an algorithm to eliminate a few constant time pointer redirections (or something) from a loop. We can keep track of the size of a list even if we never have to read it without fretting about performance loss. We can use dynamically sized arrays and not cry about all of the memory allocation and copying taking place. The cost of customizing algorithms for specific implementations no longer outweighs the development costs. Java, Hibernate, Struts, JSF, etc. have succeeded because they simplify development with negligible impact on performance.

I think the biggest difference is that Java supplies simple, understandable and re-usable code. It's written in plain English so developers don't have to commit hundreds of obscure function names to memory (strcpy, printf, sprintf, strcat, cout, endl).

C+++ could be even easier to use than Java if its creators understand that other people have to understand the language they create. Microsoft learned that lesson when updating VB. No more remembering lame function names (left, right, cint, cstr, lcase, sgn, rnd)!

[Anonymous Coward]

Dear John

You can ask a construction worker to build a house and he will probably be successful at it. Would _you_ ask him to build _your_ own house? Or would you prefer an architect/civil engineer team?

PhD's have all these abstract ideas that most people fail to understand; let's not say appreciate. BSc's are in the trenches day in and day out doing things that most of us are comfortable dealing with. Would you say that the PhD's are full of it and their work is neither useful or wanted? Would you say that just because you don't get it, what they do is worthless?

Everyone who complains about C++ seems to do so because it's hard to master and use well. You say that Java and C# are great because more and more people are able to use it. The people writing things like Boost, _are_ among the very best that the "very hard" C++ has to offer. What can you deduce from that? Do you think that they should wear one of those T-shirts that say "I'm with stupid" and an arrow pointing up? I'm sorry you feel that it's arrogance. Most likely it's just their ability to think more abstractly and grasp more complex systems easily that makes you feel like that.

Finally, answer me this. Why do you think that the JVM and Visual Studio were written in C++? Let me know when the JVM is written in Java and Visual Studio in C#.

And by the way, just so you don't think that I'm a C++ freak, I, like almost everyone above, do believe that Java is best used for some things... Just not _everything_, like the Java community seems to think.