Original URL: https://www.theregister.com/2006/10/09/c_plusplus_frameworks/
C++ Generic Coding vs. Java Frameworks
Why are there so many things that C++ developers should do by hand?
Posted in Software, 9th October 2006 05:10 GMT
Column 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 technology. So why are there so many things the C++ developer must do by hand, which a Java developer can do by reusing existing code?
Is the lack of these frameworks and libraries one of the reasons why the language is losing ground to Java? In this article, I shall examine these points to see if they’re true; and attempt to determine the obstacles to greater code reuse in C++.
Before we start out, let's get a common picture of what type of code we want to reuse. We’ll start by making a distinction between two types of reusable code; a plain old library containing factorised code and the more interesting case containing tools, code-generators and support libraries that provide a means of transforming between the different domains of a data model. An example of the second is an SQL abstraction framework that takes a representation of the SQL schema and generates classes so that the relational data model can be manipulated in the object oriented domain.
In general, the problem of manipulating data in a foreign domain is tedious and time consuming. One approach to interfacing with databases is to call an interface library, perhaps ODBC or even something more proprietary. Such libraries will present everything needed to access the data in its relational form; the code to maintain integrity in the relational model [in purist terms, a proper RDBMS - relational database management system - should maintain its own integrity without relying on the programmer – ed] and the deletes and update code must be written by hand.
This hand-written code is tedious, time-consuming to write and if not carefully managed it will create dependencies on the database interface library everywhere. With an SQL abstraction framework, we use a description of the data model to generate both the SQL and all the code mentioned above.
In other words the mapping from relational to object model is now expressed in generated code, which means, firstly, that it doesn’t need to be written by hand; and, secondly, that the details of handling relational data and interfacing with a database are hidden behind an object oriented interface. Most of us will agree that generating this data model transformation is a significant saving in time compared to writing it by hand. In addition, using the generated object oriented interface means that the code using the database can focus on what it needs to do rather than the details of handling relational data and interfacing with the database.
An example of such a framework in Java is Hibernate. Similar tools for XML and other technologies are plentiful in Java. In C++ this infrastructure is harder to find; it exists but normally needs to be paid for or isn’t as dependable as the Java equivalent. So why is it that we see more of such infrastructure in Java as opposed to C++?
Is it just that Java is the obvious choice of technology for anything involving XML or databases and these frameworks don’t exist in C++ because nobody would use C++ for this type of problem? I’m not sure that this is so self-evident; the languages are not so different that something modelled in one cannot be modelled in the other with more or less the same level of difficulty.
However, just as portability is often a strong argument for using Java for a problem, there is also often a performance argument for using C++; and, for this reason, you could expect that some programmers in any problem space where Java is applied would sometimes prefer C++ solutions.
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! ®