Porting C++ Template to Java Generic

Discussion in 'Java' started by Aadain, May 17, 2008.

  1. Aadain

    Aadain Guest

    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, May 17, 2008
    #1
    1. Advertising

  2. Aadain

    Stefan Ram Guest

    Aadain <> 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.
    Stefan Ram, May 17, 2008
    #2
    1. Advertising

  3. "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > Aadain <> 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.
    Chronic Philharmonic, May 17, 2008
    #3
  4. Aadain

    Stefan Ram Guest

    "Chronic Philharmonic" <> 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.
    Stefan Ram, May 17, 2008
    #4
  5. Aadain

    Aadain Guest

    On May 17, 12:19 pm, "Chronic Philharmonic" <>
    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, May 19, 2008
    #5
  6. Aadain

    Daniel Pitts Guest

    Aadain wrote:
    > On May 17, 12:19 pm, "Chronic Philharmonic" <>
    > 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;
    }
    }

    MyInt total = DoesSomeWork.sumOf(myIntList);

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, May 19, 2008
    #6
  7. "Aadain" <> wrote in message
    news:...
    > On May 17, 12:19 pm, "Chronic Philharmonic" <>
    > 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.

    AHS
    Arved Sandstrom, May 19, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Murat Tasan
    Replies:
    1
    Views:
    8,038
    Chaitanya
    Feb 3, 2009
  2. Michele
    Replies:
    3
    Views:
    514
    Glen Low
    Oct 6, 2003
  3. Replies:
    2
    Views:
    433
  4. johanatan
    Replies:
    6
    Views:
    381
    James Kanze
    Feb 19, 2008
  5. minlearn
    Replies:
    2
    Views:
    453
    red floyd
    Mar 13, 2009
Loading...

Share This Page