Skip to main content

Pass by reference - why not?

68 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
peter_lawrey
Offline
Joined: 2005-02-24

> Of course malloc, realloc, and free are exceptions to that, we REALLY MUST HAVE THOSE NOW!!!!!!!!!

Too late. :)
Have a look at sun.misc.Unsafe, introduced in Java 1.2

public native long allocateMemory(long l);
public native long reallocateMemory(long l, long l1);
public native void setMemory(long l, long l1, byte b);
public native void copyMemory(long l, long l1, long l2);
public native void freeMemory(long l);

jwenting
Offline
Joined: 2003-12-02

> > Of course malloc, realloc, and free are exceptions
> to that, we REALLY MUST HAVE THOSE NOW!!!!!!!!!
>
> Too late. :)
> Have a look at sun.misc.Unsafe, introduced in Java
> 1.2
>
> public native long allocateMemory(long l);
> public native long reallocateMemory(long l, long
> long l1);
> public native void setMemory(long l, long l1,
> l1, byte b);
> public native void copyMemory(long l, long l1,
> l1, long l2);
> public native void freeMemory(long l);

Not part of the core language, the sun.com packages are not to be used in application development (this is official Sun policy) but are for internal JVM use.

Anyway these shouldn't be class members, they should be operators!

For example
[code]Object[] boobs malloc 10 Booby[/code]

should allocate memory for an array of 10 Booby objects, but allow anything to be mapped into that space.

peter_lawrey
Offline
Joined: 2005-02-24

> void get(Object* owner, int type, int& index, BaseTable*& tbl )

To repeat a previous poster, use an OO design and you won't need to do anything like this.

My first language was assembly and much later C/C++. I would still suggest you use an OO design, even in C++.

hlovatt
Offline
Joined: 2003-11-18

It is trivial to achieve the same effect, and more (think about equals, hashCode, get, and set - see below), with a tuple class, e.g.:
[code]
public class Tuples {
...
public static class T1< E1 > {
public E1 e1;
public T1() {}
public T1( final E1 e1 ) { this.e1 = e1; }
public boolean equals( ... ) { ... } /* equals and hashCode allow it to be used in a map */
public int hashCode() { ... }
public E getE1() { return e1; } /* get and set allow tools that understand beans to use the tuple */
public void setE1( final E1 e1 ) { this.e1 = e1; }
}
public static < E1 > T1< E1 > t( final E1 e1 ) { return new T1< E1 >( e1 ); } /* Uses type inference to deduce type including generics and therefore saves typing */
...
}
[/code]
And you can add versions of tuples that do primitives as well, i.e. TI for ( int ), TII for ( int, int ), TID for ( int, double ), etc. You can extend T1 to make T2 and so on.

To use the class use a static import:
[code]
import static Tuples.*;
...
void get( Object owner, int type, TI index, T1< BaseTable > tbl ) { ... }
...
TI index = t( 1 );
T1< BaseTable > tbl = t( new BaseTable( ... ) );
get( owner, type, index, tbl );
[/code]
There is no evidence to suggest that creating small objects is a bottle neck in Java programs running on current JVMs. Therefore use tuples to save the creation of large objects and you have achieved the effect you want.

In summary, why add a language feature for something that is so simple to do already and as many people have pointed out in this forum is of dubious value in the first place :)

u5321007
Offline
Joined: 2003-08-06

> In summary, why add a language feature for something
> that is so simple to do already and as many people
> have pointed out in this forum is of dubious value in
> the first place :)
All your assumption is smll object cretion won't hurt performance, but do you have benchmark?
Compare to your solution, pass by reference is still much lear than yours.

Maybe pass by reference is not easy to understand for newbie, but I think java is not design for newbie only. I need advance feature, and not always use JNI to do low level code.

hlovatt
Offline
Joined: 2003-11-18

The figures I am going to give below are out of date now, so you would expect much faster than this on a modern computer with a modern JVM, but:

http://www.oreilly.com/catalog/javapt/chapter/ch04.html#_Toc474748094

Says:

"There are already runtime systems that use generational garbage collection, minimize object-creation overhead, and optimize native-code compilation. By doing this they reach up to three million objects created and collected per second (on a Pentium II)"

This would seem to be pretty fast to me, about a third of a micro (not milli but micro) second per object on a PII :)

Also why is special syntax for passing by reference easier to understand than objects? If you are using Java you must already know about objects and they are quite capable of passing by reference whereas new syntax means more syntax to learn and more concepts to learn. Why is the C++ syntax better? Is:
[code]
void get( Object owner, int type, int& index, BaseTable& tbl )
[/code]
Significantly better than:
[code]
void get( Object owner, int type, TI index, T1< BaseTable > tbl )
[/code]
And I mean sufficiently better to warrent a change! In your application you can just read the tuple wrappers, TI and T1, as meaning pass by reference.

jwenting
Offline
Joined: 2003-12-02

> Using reference parameters a lot sounds like a design
> smell. Perhaps the C++ code uses it mostly to avoid
> copying objects (which Java does automatically)?
>
> Better use proper OO style instead.
>
Well said.

> > I do really hope it can support in mustang or
> dolphin.
>
> Sure, right alongside multiple inheritance, multiple
> return values, operator overloading, const, unsigned,
> delete, and all the rest. In fact, Java will be
> exactly the same language as C++. Oh joy!

Even better said :)

It's time people stopped screaming about how they want XXXXX to be added to the language because YYYYY has it.

Of course malloc, realloc, and free are exceptions to that, we REALLY MUST HAVE THOSE NOW!!!!!!!!!

boereck
Offline
Joined: 2005-07-17

> > Sure, right alongside multiple inheritance,
> multiple
> > return values, operator overloading, const,
> unsigned,
> > delete, and all the rest. In fact, Java will be
> > exactly the same language as C++. Oh joy!
>
> Even better said :)
No, you forgot the delegates with the ingenious += assignment :D

> It's time people stopped screaming about how they
> want XXXXX to be added to the language because YYYYY
> has it.
>
> Of course malloc, realloc, and free are exceptions to
> that, we REALLY MUST HAVE THOSE NOW!!!!!!!!!

Seriously, comments like this got me the picture, that some people here are very ignorant/conservative. I guess in the discussion about java 1.5 you wanted to keep the for-in/for-each loop "dirt" out of java. Sorry for being so harsh, but not everything that comes from other languages is bad by definition. On the other hand many things neither help to understand the code with a precise syntax nor are easy and fast to write, I admit that. Memory-management for example should stay out of java. Changes on java have to be done carefully.

I'm not a C++ programmer and want to have everything in java I have in C++. In fact I am a IT-student and am interested in programming-concepts. Is call by reference such a OO-killer? Would we all never use objects if there was call-by-reference? I doubt that. In my opinion static-functions are less OO than call-by-reference. In several situations I used wrapper-objects for call-by-reference replacement. Object creation can be a sideeffect (I don't know if that is bad style, but it is an example from my personal experience). In that context multiple return-values (can be reached by call-by-reference) also makes sense.
Perhaps I am wrong and you know a study about how call-by-reference harms OO-programming and makes code less understandable. I believe that call-by-reference is an addition to OO-programming not a replacement (until the opposite is proven :) )

hithacker
Offline
Joined: 2004-11-25

To, ramimahdi

>This debate is the same as the debate of operator overload. Why not sun just put us (the programmers) these options and leave it to us either to use or not.

>I beleive that the JDK top engineers are old people who are stuck to the old days of programming and follow a conservative approach in developing java.

Mr.ramimahdi, btw james goshling and JDK top engineers r much intelligent then us.In my opinion what sun doing is right thing.they can't let anyone change their language.CLASS IS ALWAYS BETTER THEN MASS.

ramimahdi
Offline
Joined: 2004-05-29

I beleive a language of the future must be extensible in coding. it should adapt the programmers' way of programming.

I don't why exaggerate that much in adding such property. Look and how much it is easy in C#

methodname(ref int x, ref int y).

Lets sun put this feature and leave the programmer decide whether to use or not.

Many times we need to do things quickly (on the fly) and not spent hours looking for perfect design.

What I don't understand is why don't you just put these option and the option of operator overloading there and let us choose whether to use or not.

I beleive all the counter arguments in both: this topic and the topic of operator overloading are aiming to convince programmers that this the right. And releive sun from putting any investment in applying these great features.

I like writting C# code because I feel it adapts my style of programming. I feel it is very extensible.

If sun problem is "resembling C#". Then they are wrong because most C# was resembling Java. So taking feature from C# won't be a shame

hithacker
Offline
Joined: 2004-11-25

To, ramimahdi

>This debate is the same as the debate of operator overload. Why not sun just put us (the programmers) these options and leave it to us either to use or not.

>I beleive that the JDK top engineers are old people who are stuck to the old days of programming and follow a conservative approach in developing java.

Mr.ramimahdi, btw james goshling and JDK top engineers r much intelligent then us.In my opinion what sun doing is right thing.they can't let anyone change their language.CLASS IS ALWAYS BETTER THEN MASS.

laurapiersol
Offline
Joined: 2003-06-13

I've been sucked in because the rhetoric here seems to be getting much higher then the science. So lets review.

1.) People are idiots who don't agree with me. Now that's just a given so not worth a discussion (Hopefully everyone realizes I'm joking (kinda)). Unless we express ourselves maturely here NO ONE important (SUN) will listen. I'll listen but I'm not important and love reality tv.

2.) The definition of Object Oriented Design seems to be like the FORTRAN language. I don't know what language the scientific community will be using in the future but I KNOW they'll call it FORTRAN. Lets all get off our high horses and discuss the topic at hand - is pass by reference or multiple return values a good language feature. "Proper" language design should be about clarity, expressiveness, simplicity, readability, correctness, ...etc. Do multiple return values add value without increasing complexity? If they do then lets just call them OO.

3.) Pass by reference has MANY problems including security issues with the JVM. The only REAL problem pass by reference addresses is multiple return values. If there is multiple return values WHY would anyone use pass by reference? Example:
swap(&int a, &int b); -> [b, a] = swap(a, b);

4.) I don't believe there is even ONE person here who has ACTUALLY USED multiple return values and not found them extremely useful. Go ahead, prove me wrong.

5.) Any new language feature will need to be understood by ALL programmers whether they use it or not. We all have to read other peoples code. Lets only promote features that add value and clarity to the language, not complexity. Do multiple return values had value and clarity without increasing complexity? Yes, yes, yes!

6.) Why has this topic moved to "Pass by reference"?

rogerhernandez
Offline
Joined: 2005-02-23

[i]3.) Pass by reference has MANY problems including security issues with the JVM. The only REAL problem pass by reference addresses is multiple return values. If there is multiple return values WHY would anyone use pass by reference? Example:
swap(&int a, &int b); -> [b, a] = swap(a, b);[/i]

I agree with you that multiple return values would cover pretty much all the cases where one would use pass by reference. The only case where pass by reference would be useful would be in inner loops in performance critical code, on functions the compiler can not inline. However this kind of code exists in a very small fraction of applications most developers work on.

Can you go into more details on the problems with the VM and security with respect to pass by reference?

podlesh
Offline
Joined: 2004-07-26

One more note: pass by reference is in C/C++ used mostly (and this is perfect example) as a hack to implement multiple return values.

sjasja
Offline
Joined: 2004-08-15

Using reference parameters a lot sounds like a design smell. Perhaps the C++ code uses it mostly to avoid copying objects (which Java does automatically)?

Better use proper OO style instead.

> I do really hope it can support in mustang or dolphin.

Sure, right alongside multiple inheritance, multiple return values, operator overloading, const, unsigned, delete, and all the rest. In fact, Java will be exactly the same language as C++. Oh joy!

u5321007
Offline
Joined: 2003-08-06

> Using reference parameters a lot sounds like a design
> smell. Perhaps the C++ code uses it mostly to avoid
> copying objects (which Java does automatically)?
>
> Better use proper OO style instead.
Then, please tell me what is proper OO style?
I hear enough this kind of sarcasm.
I don't understand what do you mean "copying object automatically", perhaps , firstly, you need understand java pass primitive type and object handler by value. I believed you totally misunderstand this. This case use pass reference is for using parameter as return value, perhaps you can understand clearly if I write down the C++ code

void get(Object* owner, int type, int& index, BaseTable*& tbl )
>
> Sure, right alongside multiple inheritance, multiple
> return values, operator overloading, const, unsigned,
> delete, and all the rest. In fact, Java will be
> exactly the same language as C++. Oh joy!
Again, I strong believe simple is important, too.
But you can see how ugly it is without pass by reference.
I shows my view point, did you ? I just hear your complain.

People say variable argument is not necessary for java several years ago. Now what ? If simple is good enough why they add generic and even consider XML support ?

podlesh
Offline
Joined: 2004-07-26

Problem with the style you use (multiple return arguments via pass by reference) is that it breaks one of the base rules of OO: encapsulation. Data should be held together in objects, forming logical data units.

You should return result object, which contains all result data (in this case: index, table). That's the "most correct" OO approach.

If the object creation it too much overhead for you, use this object as value object:
void storeTable(Owner owner, int type, BaseTable value) {
value.setIndex(...); //use field if too much overhead...
...
}

u5321007
Offline
Joined: 2003-08-06

> Problem with the style you use (multiple return
> arguments via pass by reference) is that it breaks
> one of the base rules of OO: encapsulation. Data
> should be held together in objects, forming logical
> data units.
>
> You should return result object, which contains all
> result data (in this case: index, table). That's the
> "most correct" OO approach.
>
> If the object creation it too much overhead for you,
> use this object as value object:
> void storeTable(Owner owner, int type, BaseTable
> value) {
> value.setIndex(...); //use field if too much
> ch overhead...
> ...
> }
This approach has no difference to pass a object array as a return value container(that I have write at first post). You still HAVE to allocate object for it. This is not good for high performance code and error prone.

Yes, this is defnitely a multiple return, but I perfer it. It's clean and simple than multiple return.