Re: Using pointers in Java

From: chris (chris_at_kiffer.eunet.be)
Date: 01/31/04


Date: Sat, 31 Jan 2004 17:35:27 +0100

Funny, I was just saying to someone yesterday: "Java is not a replacement
for Fortran". For the project in question we took it as understood that the
number-crunching would be performed in C.

One alternative to your "arrays of one element" proposal would be to put
all three parameters into a single array:

void add(double[] a) {
  a[0] = a[1] + a[2];
  a[1] = a[0] + a[2];
}

In both cases you'll have array bounds checking overhead, which I don't
think the JIT compiler will be able to optimise away (could be wrong there).

Or alternatively:

class Triple {
  double a1, a2, a3;
}

void add(Triple t) {
  t.a1 = t.a2 + t.a3;
  t.a2 = t.a1 + t.a3;
}

That does at least look object-oriented, and should generate reasonably
efficient bytecode. Whether it really _is_ object-oriented depends on
whether t corresponds to anything recognisable in your problem domain ...

HTH

Chris

S Manohar wrote:

> I need to pass a 'reference' to a double value to a function which
> changes that value. Each time the function is called, it needs to
> change different sets of values. In C I'd simply pass references.
>
> void add(double *a1, double *a2, double *a3){
> *a1 = *a2 + *a3;
> *a2 = *a1 + *a3;
> }
>
> In Java, one solution would be to create a class to represent a
> mutable value:
>
> public class MutableDouble {
> private double value;
> public final void set(double value){ this.value=value; }
> public final double get(){ return value; }
> }
>
>
> But, my this is cumbersome in my code for several reasons:
>
> 1) My code contains many long mathematical equations, which become
> very convoluted using this syntax, with ridiculous numbers of
> parentheses! It is very important that the maths in the code is
> readable, as someone else may have to work on my code. E.g.,
> a = a + 1
> becomes
> a.set(a.get()+1)
> The problem is, of course, that unlike C++, operators cannot be
> defined.
>
> 2) get() and set() will presumably be slower than direct use of
> values. Though I don't know enough about how the javac inlines
> functions.
>
> 3) I need to define a MutableInteger, MutableLong and MutableFloat as
> well.
>
> 4) The size of the compiled code will be, presumably, more bulky.
>
> So, This is the kind of solution I am thinking of adopting:
>
> void test(){
> double[] x=new double[1], y=new double[1];
> add(x,y,y);
> }
>
> void add(double[] a1, double[] a2, double[] a3){
> a1[0] = a2[0] + a3[0];
> a2[0] = a1[0] + a3[0];
> }
>
>
> Using arrays of length 1 as pointers has some advantages, seems
> 'cheap' in terms of code and memory, and the code will look much nicer
> than using get/set. But naturally there are disadvantages, e.g., as
> with pointers, there's the potential for inadvertent null-pointer
> exceptions (which will be ArrayIndexOutOfBounds exceptions).
>
> Has anyone used this method?
>
> Has anyone any comments on its effectiveness and/or problems?
>
> What is your opinion on its methodological purity?
>
> Sanjay

-- 
Chris Gray      chris@kiffer.eunet.be
/k/ Embedded Java Solutions


Relevant Pages

  • Re: seeking advice for "translate" Fortran code to Java code
    ... redefine a common block as needed for each subroutine. ... Still, Java has no pointers, so I ... Java arrays are always what C would call arrays of pointers ... Fortran intrinsics in Java appropriately. ...
    (comp.lang.fortran)
  • Re: seeking advice for "translate" Fortran code to Java code
    ... with these features that just don't exist in Java: ... Labeled COMMON blocks Blank COMMON ... Java arrays are always what C would call arrays of pointers ... FORTRAN I/O class that would emulate formatted and binary I/O. ...
    (comp.lang.fortran)
  • Re: Java und Effizienz
    ... Statt dessen sollte man nur Arrays und Schleifen verwenden ... Die meisten Parser (in Java) sind langsam weil die Leute Stringverarbeitung nicht im Griff haben. ... In Java musst du übrigens bedenken, dass alle Array-Zugriffe eine Indexprüfung beinhalten, sodass Zugriffe auf Arrays teurer sind als Zugriffe auf Exemplarvariablen von Objekten. ...
    (de.comp.lang.java)
  • Re: Java Generic programming using subclassing
    ... >> form into the standard Java syntax. ... >> derivative language that has multidimensional arrays where Java does not? ... the major high-level languages and should be allowed to use this terminology without ...
    (comp.lang.java.programmer)