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?
> 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.
Stefan Ram wrote: > "Chronic Philharmonic" <karl.uppi...@verizon.net> writes: >> 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.
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.
On May 17, 12:19 pm, "Chronic Philharmonic" <karl.uppi...@verizon.net> 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?
Aadain wrote: > On May 17, 12:19 pm, "Chronic Philharmonic" <karl.uppi...@verizon.net> > 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());
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; }
> On May 17, 12:19 pm, "Chronic Philharmonic" <karl.uppi...@verizon.net> > 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?
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.
