Porting C++ Template to Java Generic

[Aadain]

I've run into a road block with porting some C++ code that makes use
of templates to Java. In it, there is a main class I'll call A that
is a template class:

// C++
template <class T> class A
public:
virtual T Evaluate() const = 0;
};

Other classes extend this class:

// C++
template <class T> class B : public A<T> {
public:
B(const T &v) { value = v; }
T Evaluate() const { return value; }
private:
T value;
};

Now all of this is easy to implement in Java using Generic
programing. The issue I'm having is when I try to implement code like
this:

template <class T1, class T2> class C : public A<T2> {
public:
C(A<T1> a, A<T2> b) { t1 = a; t2 = b; }
T2 Evaluate() {
return t1->Evaluate() * t2->Evaluate();
}
private:
A<T1> t1;
A<T2> t2;
};

Java complains about about the * operator being undefined for
arguments T1, T2; Since Java doesn't have operator overloading, I
can't really see how to implement the same functionality. Has anyone
ever encountered this type of problem, or can anyone see a way around
this issue?

 

[Stefan Ram]

Has anyone ever encountered this type of problem,
or can anyone see a way around this issue?

In Java, »*« only applies to primitive types, which cannot be
type arguments.

On this low level you would need to define an implementation
of »multiply« for each relevant type and use »a.multiply(b)«
or »multiply(a,b)« or so depending on the type of dispatch
(static or non-static) wanted for each argument.

Often, it will be better to re-design and re-implement in Java.

 

[Chronic Philharmonic]

In Java, »*« only applies to primitive types, which cannot be
type arguments.

On this low level you would need to define an implementation
of »multiply« for each relevant type and use »a.multiply(b)«
or »multiply(a,b)« or so depending on the type of dispatch
(static or non-static) wanted for each argument.

Often, it will be better to re-design and re-implement in Java.

I inherited a "Java project" that was ill-advisedly ported from both C and
C++. The Java code had in/out parameters, HVALUE type return types that you
had to check (without the benefit of the Win32 "cracker" macros -- instead
of throwing/catching exceptions), and monstrosities such as "MutableInt". It
was not Java, it was Win32 and/or C and/or C++ that you could compile down
to Java byte codes and run in a JVM.

The sad thing was, when the project was ported to Java, it severed its ties
to the original native code base, so the only argument for the port was
slightly faster time to market, or slightly less development cost than
starting over in Java. I do not believe those arguments were validated, and
even if they were, any gains were more than offset by the very high cost of
maintenance over the years of the product's useful life.

Port the design, not the code.

 

[Stefan Ram]

Port the design, not the code.

If the code was already ported, it might still be improved by
refactoring - which includes writing unit test before any
modifications are made.

But this also takes some time to do. If you are not granted
pay to do this, then it can't be done; but each other paid
change to be done will take longer and be more error-prone.

 

[Aadain]

Port the design, not the code.

This is exactly what I am attempting to do. I've porting the
functionality of the program, which itself is pretty efficient and
mostly language neutral. There were plenty of operations that took
advantage of C++ functionality, such as the original problem I
demonstrated in the original post. After doing some digging and some
thinking on my own, I'm beginning to think that the solution is create
a simple master class that implements basic math for all possible
types that the generic types will take (there are only a handful) and
requiring the generic class to extend that master class. Then instead
of the command

return t1.Evaluate() * t2.Evaluate();

It would look like

return t1.Evaluate().mult(t2.Evaluate());

Has anyone else done something similar with generics before?

 

[Daniel Pitts]

This is exactly what I am attempting to do. I've porting the
functionality of the program, which itself is pretty efficient and
mostly language neutral. There were plenty of operations that took
advantage of C++ functionality, such as the original problem I
demonstrated in the original post. After doing some digging and some
thinking on my own, I'm beginning to think that the solution is create
a simple master class that implements basic math for all possible
types that the generic types will take (there are only a handful) and
requiring the generic class to extend that master class. Then instead
of the command

return t1.Evaluate() * t2.Evaluate();

It would look like

return t1.Evaluate().mult(t2.Evaluate());

Since Java doesn't support operator overloading, that does make sense.

Has anyone else done something similar with generics before?

You don't even *need* generics for this, you *can* use a simple
interface, although it could help.

interface Addible<R,T> {
R add(T t);
}

class MyInt extends Addible<MyInt, MyInt> {
private final int value;
public MyInt(int value) {
this.value = value;
}
public MyInt add(MyInt other) {
return new MyInt(value + other.value);
}
}

public class DoesSomeWork {
public static <T extends Addible<T,T>> T sumOf(Collection<T> addable){
Iterator<T> it = addible.iterator();
if (!it.hasNext()) {
return null;
}

T current = it.next();
while (it.hasNext() {
current = current.add(it.next());
}
return current;
}
}

MyInt total = DoesSomeWork.sumOf(myIntList);

 

[Arved Sandstrom]

This is exactly what I am attempting to do. I've porting the
functionality of the program, which itself is pretty efficient and
mostly language neutral. There were plenty of operations that took
advantage of C++ functionality, such as the original problem I
demonstrated in the original post. After doing some digging and some
thinking on my own, I'm beginning to think that the solution is create
a simple master class that implements basic math for all possible
types that the generic types will take (there are only a handful) and
requiring the generic class to extend that master class. Then instead
of the command

return t1.Evaluate() * t2.Evaluate();

It would look like

return t1.Evaluate().mult(t2.Evaluate());

Has anyone else done something similar with generics before?

I may be missing something in what you are trying to do, but this doesn't
seem to be a problem for generics. If you only have a small number of
classes, each supporting a certain set of methods (like mult()), then there
are two main choices for implementation - inheritance or interfaces. I don't
know enough about the classes in question to suggest which one would be
best, but I'm pretty sure you don't need generics.

AHS