C++ Generic Coding vs. Java Frameworks

A possible explanation of this difference in availability of infrastructure is the approach to standardization in the two languages. C++ standardization aims to make the language as coherent as possible and to give clean support to abstraction paradigms such as object orientation and generic modelling.

The C++ standard defines the tools for object orientation and generic modelling without reference to the problems that they solve. There are no references in the C++ language standard to specific software development problems or how they might best be solved. Defining a language is complex enough without standardizing its applications. It can be equally argued that if a tool is made specific to a specific problem then the tools is less flexible when applied to other problems.

On the other hand, there is Java, where its inventors have standardized architectures for entire classes of problems. J2EE effectively describes how to architect and implement the distributed transactional systems common in the world of web commerce. The standardized architecture means that each system will have similar applicative layers; all offering the possibility of using libraries and framework solutions for subparts of the problem. The frameworks themselves sit on the Java runtime and as this makes them as portable as Java itself, they can be used wherever it makes sense to use them.

A value of C++ is, as much as possible, to be self-consistent on each and every platform. Databases, XML and other libraries do not exist universally and there is an argument that they should not be included in the language standard because they cannot be provided consistently.

Different platforms have different system interfaces and in all likelihood, the libraries used to allow a framework to function will not always be available. However, this apparently fundamental problem doesn’t stand up to analysis; as we said earlier frameworks present interfaces related to what the developer needs to do.

In the worst case, the implementations behind these interfaces will differ dramatically from platform to platform but if it is not possible to implement the interface then that just means that the platform doesn't support the requisite technology and, as such, is not a valid technology choice.

Furthermore, the presence of a standardised interface means that technology providers can design their technology in conformance to the standard; consequently, the variance from platform to platform shouldn’t be so dramatic. So, when porting the framework it may, in the worst case, be necessary to provide a specific implementation for the target platform but afterwards all code using the framework will function normally.

What we tend to see more in C++ is newer and cooler ways to express algorithms. The Standard library, Boost and many others are impressive for the clever use of templates in combination with more traditional techniques. They provide us with algorithms and types that enable us to hide the mundane mechanics of selection and iteration behind template instantiations and to focus the code on concise and generic operations on data.

However, the argument above is that writing loops and if statements are not the things which take up most of the time when writing code. More time is spent working out the interfaces to external systems and transforming data models from one domain to another. So are the library writers of C++ giving too much focus to cool stuff with templates? Is what we need a little more focus on the less cool problem of interfacing with a database or processing XML? If such infrastructure existed, would C++ be an easier language to learn for newcomers? To summarise, why doesn’t C++ have the same free and high quality, solutions to database abstractions and XML processing that exist in Java?

In the next article, we shall take this abstract discussion to a practical level by looking at this Hibernate framework to see if there’s any reason why it shouldn't exist in C++. We're looking forward to incorporating your points of view so please leave feedback so we can develop this discussion further! ®