Is Java a good language to learn Besides C++ ??

Pages: 12345
That's an answer I can live with. I suppose from an OOP point of view, Objects represent more than "a collection of data".

On a different note: after looking up the implementation of a Linked List in java, I'm quite convinced I'll never go back there. It looks a lot cleaner than I expected (auto-referencing has its charms), but I couldn't live with the whole "delete by forgetting".
http://stackoverflow.com/questions/10042/how-do-i-implement-a-linked-list-in-java
1
2
3
int a[10] = { <numbers> };
int b[10];
b = a;
You know that that doesn't compile.

Statement 3 is incorrect. I could cut your arms, but you will still be you.
Statement 4 is not necessary.

When you say b := a. you are saying 'b and a are the same thing'. So it's obvious that if you modify b, a will be modified. (they are the same).
When passing an object as an argument you are doing arg := obj.
So when you talk to the argument you are talking against that object

Now just take these as rules of the language:
"You can't change the identity of your arguments"
"You can't change your identity" (let's just say that assignment is not a message)


If you want a copy then you should ask the object to copy itself (sending it a message)
1
2
3
b := a copy.
b := a shallowCopy.
b := a deepCopy.
Last edited on
What is wrong with "delete by forgetting"? When you delete a pointer in C++, it also doesn't return the memory to the OS immediately (and often never returns). Thanks to delete by forgetting you can make cost of deletes essentially 0.
Last edited on
Gaminic wrote:
I know that. I know what happens behind the scenes. I'm asking why you would want it that way.
While you did have that at the end of your post you also had

Now, please answer me without juggling semantics why "Java passes by value" still holds when I can change the value of member of an Object passed by value.

Or, the other way around, explain to me how the following (conceptually) makes sense:
1
2
3
4
Point A = new point(50, 50);
Point B = A;
doSomethingWith(B);
// A is now changed  
@ne555:
Statement 3 is incorrect. I could cut your arms, but you will still be you.


That's not the meaning I attached to that statement. I was trying to prevent "The parameter isn't changed, because the reference is the parameter".

Anyway, you're assigning value to the concept of "you" (which makes sense in an OOP point of view, but is completely meaningless in a data-bcentric view). If you cut off my arms, I'm still me, but I'm changed. Hence, why I said, changing a member of an Object changes the Object (it's still the same Object, but it has changed).
I thought that we were discussing OOP here.
There is difference between class, instance of a class, and state of an instance.
It just doesn't allow you to change the instance of the arguments (or your self)
So it's obvious that if you modify b, a will be modified. (they are the same).
You mean, if you modify what is being referred to by the references. If you make one refer to null, it doesn;t affect the other.
Not really. I was debating whether "Java passes everything by value" is a valid statement, since you can change the data members (state?) of an object "passed by value" (which in my eyes refutes the 'by value' part conceptually, even though it's technically correct). I find that it leads to confusing, inconsistent behaviour.

From an OOP point of view, the 'everything is a reference' mentality makes sense to me. If 'you' means anything beyond 'your eye colour + your age + your name + ....' (collection of attributes), then it makes sense to conceptually separate the Object and its reference.
Java pass primitives by value by deep copy and others by shallow copy. ¿would that be correct? (edit: false)

@LB: More like, the messages send to 'b' are send to 'a' (as they are the same). But yes, thanks for the correction.
I wanted to avoid mention reference (implementation details) and just get the idea of what was happenning and why.


From an OOP point of view, I like the 'everything is an object, and objects communicates trough messages'.
Then there is no need to talk about references.
But I would need to study the assignment more closely (¿is it a message? ¿who is receiving it?)

¿Are the messages objects? ¿how could you send a message to a message?
Last edited on
First find out what pass by value means, then you can understand what evaluation strategy Java uses.
¿Are there values in java?
Yes. You can't assign to values:
1
2
3
4
5
6
static Object getObj(){ return new Object(); } //not important

//...

getObj() = new Integer(); //cannot assign to value
Object o = new Integer(); //can assign to reference/variable 
Same for the other primitive types.

This is where compiler errors get weird ;)
Last edited on
closed account (1yR4jE8b)
In Java, *everything* is passed by value. The gotcha is that Java objects are basically pointers without pointer-arithmetic. So when you pass an object into a function, you are passing-the-pointer-by-value.
Why is it that the most prolific posters are often the most confused? ;-)

The different calling strategies have been well defined and understood long before there was a Java or a C or a C++.

It seems that a couple of people in this thread are having difficulties because they are confusing the terms "call by value" and "values" and "call by reference" and "references". These are mostly unrelated terms.

Back in the old days, computer languages chose from the 3 usual strategies, call by value, call by reference and "call by name" (thankfully, that one didn't become the norm). Part of the reason that these all existed was that high level languages were relatively new and there was not enough experience to decide yet which was best.

But now we know, don't we: Call by value ;-) C and Java are strictly call by value languages by definition. It never meant that one could not pass a reference so that the object pointed to may be changed by a function. Technically, with call by value, the function can never change the original parameter. If you pass a reference to a variable like f( &in ), you can change "in", but you cannot change the passed value (a manual reference) so that it is remembered when the function returns.

A good question might be... if call by value is so good, why does C++ give you both?

As far as I'm concerned (and someone can enlighten me here), the only reason that C++ gives you the ability to pass by reference is so that a function can return multiple values without having to define yet another class to hold the multiple values. This is also a weakness in Java (but not Python). I think using pass by reference for any other reason is weak code.

I'm often amused by C++ vs Java debates, which are usually conducted by people without enough experience in both. My favorite argument is how one has features missing in the other. The problem with C++ is that it has features that should never, ever be used. (Yes, some will cry for an example, how about non-virtual destructors). I think the biggest problem with C++ is its age, and the lack of a good revising. Not to mention the lack of really good libraries. (please don't mention boost).

@OP: Java is a great language to learn because you will likely learn proper OO design much better than if you try to do it in C++.

@rapidcoder: A very nice list on Java. Imutable objects are great, not just for possible performance enhancement, but also for something which is quite pathetic in C++.... multi-threading.

I'm amused that someone mentioned "delete by forgetting". Yes, if you express it this way, it does make it seem wrong how Java and C# operate. But once you start developing large scale OO systems, you will prefer this, I guarantee it. There is nothing more annoying than sharing objects in multiple collections, and when you remove an object from one of the collections, you have to see if it is present in any other collection before you delete it. Which means of course that any function that does such an operation *must* be aware of all other possible data structures that may also reference the object. Then put multi-threading on top of that. Of course, you end up avoiding this problem by having a super collection of all objects you ever created so that at the end you can properly delete them ;-) instead of deleting them when you remove them from their respective collections. Do you get what I'm saying here? It is so much easier to forget about the objects.

Last edited on
I may be very, very biased because of the work I do (which generally results in small programs with a few specialized algorithms for a single problem, and never results in large programs that are made, distributed and maintained for many years), but when I no longer need a variable, I want to be able to reclaim the memory so I can reuse it. While the programs may be small, the data sets used can be very, very large. More often than not, I call delete because I need the space for something else, not because the data is no longer necessary. That's one of the big trade-offs I make in my programs. I feel C++'s manual memory management gives me the option to do so [and all the headaches that go with it].

Of course, Java's GC might be far better at deciding when to clean up, and I might just be memory-paranoid.
A good question might be... if call by value is so good, why does C++ give you both?

As far as I'm concerned (and someone can enlighten me here), the only reason that C++ gives you the ability to pass by reference is so that a function can return multiple values without having to define yet another class to hold the multiple values. This is also a weakness in Java (but not Python). I think using pass by reference for any other reason is weak code.

Two others usages are passage by const& for performance and r-value reference(&&) for move semantics (useless in the Java world though)
Since nobody mentions "when you want the function to change a parameter", does that mean you prefer a = square(a); to square(a);?

I pass a vector<bool> by reference (not const) in a recursive algorithm, where each step sets any false boolean to true (and back to false when it returns) so signify that it's "taken". I'm not sure what the alternative would be. It makes no sense to put the vector and function in a class, and global vectors are frowned upon (plus: I want my memory back!). It's not const, it's not a return value and it's got nothing to do with move semantics.
Gaminic, your problem does not exist in Java as array are references but you know this.

Why you don't accept Java and c++ are two different languages? Personally i hate Java but for lot of non performance critical problems Java is more suitable than c++ for OOP(if that was not the case Java would not be that popular).

C++ has value semantics and no memory management, Java has entity semantics and memory management at the cost of performance, that all. With that choose your language according to your problems.
You [all] might find this video interesting. It gives a good timeline and overview of how managed languages became so popular and then presents speculation that a new era of C++ has come.
http://herbsutter.com/2011/09/07/my-c-and-beyond-intro-c-renaissance/
@aquaz: That was a genuine question, in C++. (The problem doesn't exist in Java because Java automatically does it like I do.) I'm wondering whether you two left out a reason ('necessity') or that I'm missing a(n obvious?) way of doing it differently.
Pages: 12345