Porting C++ Template to Java Generic
Aadain
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?
Chronic Philharmonic
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:multiply-20...@ram.dialup.fu-berlin.de...
> Aadain <aad...@gmail.com> writes:
>>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.
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.
Lew
> 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.
Sometimes the productivity gain from doing things right, even in the short
term, is so great that it is profitable to do it right even when you aren't
explicitly paid to do it right. You just don't tell your boss or client (same
thing) all the things you did to meet the objectives that they did state.
--
Lew
Aadain
wrote:
>
> 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
>
> Has anyone else done something similar with generics before?
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);
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Arved Sandstrom
news:66cb2495-8458-4f15...@d77g2000hsb.googlegroups.com...
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