Converting Default Arguments
One extensively used feature of C++ that Java does not support is default function arguments. For example, the area( ) function shown in the following C++ program computes the area of a rectangle if called with two arguments, or the area of a square if called with one argument.
// C++ program that uses default arguments.
#include <iostream>
using namespace std;
/* Compute area of a rectangle. For a square,
pass only one argument.
*/
double area(double l, double w=0) {
if(w==0) return l * l;
else return l * w;
}
int main()
{
cout << "Area of 2.2 by 3.4 rectangle: ";
cout << area(2.2, 3.4) << endl;
cout << "Area of 3.0 by 3.0 square: ";
cout << area(3.0) << endl;
return 0;
}
As you can see, when area( ) is called with only one argument, the second defaults to zero. When this happens, the function simply uses the first argument for both the length and the width of the rectangle.
While convenient, default arguments are not, of course, necessary. In essence, default arguments are actually a shorthand form of function overloading in which one form of the function has a different number of parameters than the other. Thus, to convert a C++ function that contains one or more default arguments into Java, simply create overloaded methods that handle each case. In this example, you need a version of area( ) that takes two arguments and another that takes only one argument. Using this approach, here is the preceding program rewritten for Java:
// Java version of area program.
class Area {
// Compute area of a rectangle.
static double area(double l, double w) {
if(w==0) return l * l;
else return l * w;
}
// Overload area( ) for a square.
static double area(double l) {
return l * l;
}
public static void main(String args[]) {
System.out.println("Area of 2.2 by 3.4 rectangle: " +
area(2.2, 3.4));
System.out.println("Area of 3.0 by 3.0 square: " +
area(3.0));
}
}
Converting C++ Multiple-Inheritance Hierarchies
C++ allows one class to inherit two or more base classes at the same time. Java does not. In both cases, subclass C inherits classes A and B. However, in the hierarchy on the left, C inherits both A and B at the same time. In the one on the right, B inherits A, and C inherits B. By not allowing the inheritance of multiple base classes by a single subclass, Java greatly simplifies the inheritance model. Multiple inheritance carries with it several special cases that must be handled. This adds overhead to both the compiler and the run-time system, while providing only marginal benefit for the programmer.
Since C++ supports multiple inheritance and Java does not, you may have to deal with this issue when porting C++ applications to Java. While every situation is different, two general pieces of advice can be offered. First, in many cases, multiple inheritance is employed in a C++ program when there is actually no need to do so. When this is the case, just convert the class structure to a single-inheritance hierarchy. For example, consider this C++ class hierarchy that defines a class called House:
class Foundation {
// ...
};
class Walls {
// ...
};
class Rooms {
// ...
};
class House : public Foundation, Walls, Rooms {
// ...
};
Notice that House multiply inherits Foundation, Walls, and Rooms. While there is nothing wrong with structuring a C++ hierarchy like this, it is not necessary. For example, here is the same set of classes structured for Java:
class Foundation {
// ...
}
class Walls extends Foundation {
// ...
}
class Rooms extends Walls {
// ...
}
class House extends Rooms {
// ...
}
Here, each class extends the preceding one, with House becoming the final extension. Sometimes a multiple inheritance hierarchy is more readily converted by including objects of the multiply inherited classes in the final object. For example, here is another way that House could be constructed in Java:
class Foundation {
// ...
}
class Walls{
// ...
}
class Rooms {
// ...
}
/* Now, House includes Foundation, Walls, and Rooms
as object members.
*/
class House {
Foundation f;
Walls w;
Rooms r;
// ...
}
Here, Foundation, Walls, and Rooms are objects that are part of House rather than inherited by House. One other point: sometimes a C++ program will contain a multiple-inheritance hierarchy simply because of poor initial design. A good time to correct this type of design flaw is when you port to Java.
Destructors Versus Finalization
When you move from C++ to Java, one of the more subtle, yet important issues you will face is the difference between a C++ destructor and a Java finalize( ) method. Although similar in many respects, their actual operation is distinctively different. Let’s begin by reviewing the purpose and effect of a C++ destructor and the Java finalize( ) method.
In C++, when an object goes out of scope, it is destroyed. Just prior to its destruction, its destructor function is called (if it has one). This is a hard-and-fast rule. There are no exceptions. Let’s look more closely at each part of this rule:
- Every object is destroyed when it goes out of scope. Thus, if you declare a local object inside a function, when that function returns, that local object is automatically destroyed. The same goes for function parameters and for objects returned by functions.
- Just before destruction, the object’s destructor is called. This happens immediately, and before any other program statements will execute. Thus, a C++ destructor will always execute in a deterministic fashion. You can always know when and where a destructor will be executed.
In Java, the tight linkage of the destruction of an object and the calling of its finalize( ) method does not exist. In Java, objects are not explicitly destroyed when they go out of scope. Rather, an object is marked as unused when there are no longer any references pointing to it. Even then, the finalize( ) method will not be called until the garbage collector runs. Thus, you cannot know precisely when or where a call to finalize( ) will occur. Even if you execute a call to gc( ) (the garbage collector), there is no guarantee that finalize( ) will immediately be executed.
While the deterministic behavior of a C++ constructor and the somewhat probabilistic aspect of finalization are of little concern in most cases, they will have an impact on others. For example, consider the following C++ program:
// This C++ program can call f() indefinitely.
#include <iostream>
#include <cstdlib>
using namespace std;
const int MAX = 5;
int count = 0;
class X {
public:
// constructor
X() {
if(count<MAX) {
count++;
}
else {
cout << "Error -- can't construct";
exit(1);
}
}
// destructor
~X() {
count--;
}
};
void f()
{
X ob; // allocate an object
// destruct on way out
}
int main()
{
int i;
for(i=0; i < (MAX*2); i++) {
f();
cout << "Current count is: " << count << endl;
}
return 0;
}
Here is the output generated by this program:
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Current count is: 0
Look carefully at the constructor and destructor for X. The constructor increments the value of count as long as count is less than MAX. The destructor decrements count. Thus, count is incremented when an X object is created and decremented when an X object is destroyed. But no more than MAX objects can exist at any one time. However, in main( ), f( ) is called MAX*2 times without causing an error! Here is why. Inside f( ), an object of type X is created, causing count to be incremented, and then the function returns. This causes the object to immediately go out of scope and its destructor to be called, which decrements count. Thus, calling f( ) has no net effect on the value of count. This means that it can be called indefinitely. However, this is not the case when this program is converted to Java.
Here is the Java version of the preceding program:
// This Java program will fail after 5 calls to f().
class X {
static final int MAX = 5;
static int count = 0;
// constructor
X() {
if(count<MAX) {
count++;
}
else {
System.out.println("Error -- can't construct");
System.exit(1);
}
}
// finalization
protected void finalize() {
count--;
}
static void f()
{
X ob = new X(); // allocate an object
// destruct on way out
}
public static void main(String args[]) {
int i;
for(i=0; i < (MAX*2); i++) {
f();
System.out.println("Current count is: " + count);
}
}
}
This program will fail after five calls to f( ), as this output shows:
Current count is: 1
Current count is: 2
Current count is: 3
Current count is: 4
Current count is: 5
Error — can’t construct
The reason the program fails is that garbage collection does not occur each time f( ) returns. Thus, finalize( ) is not invoked, and the value of count is not decremented. After five calls to the method, count reaches its maximum value and the program fails.
It is important to emphasize that precisely when garbage collection occurs is implementation dependent. It is possible that for some implementation of Java, on some platform, the preceding program will function similarly to its C++ version. However, the point of the example remains: In C++, you know when and where a destructor will be called. In Java, you do not know when or where finalize( ) will be executed. Therefore, when porting code from C++ to Java, you will need to watch for instances in which the precise timing of the execution of a destructor is relied upon.
No comments:
Post a Comment