Look Around You posted:

I guess it's strange because in most contexts you expect it to auto-(un)box so intuitively it should work. But it doesn't there.

The following prints "true" for example:

code:

public class Test {
  public static void main(String[] args) {
    Integer i = new Integer(5);
    int j = 4;
    if (i + j == 9) {
      System.out.println("true");
    } else {
      System.out.println("false");
    }
  }
}

e: 8 space indents -> 2 spaces for less huge rear end tabs.

Internet Janitor posted:

I don't really see what's so strange about it.

code:

((Integer)null).equals(new Object()); // throws NullPointerException

JewKiller 3000 posted:

Well, compare to the situation in C, where there are no references. If you want to pass some value to another function, and make it so that any changes made by that function to the value also affect your copy, you can't do that directly. You have to pass the function a pointer to the value. So, all your call sites get &s on the values, the function you're calling has to change the type of that parameter from "whatev param" to "whatev *param", and every param.foo in the function body changes to param->foo.

Kind of annoying, how about the C++ solution? Here you can actually pass by reference. All you do is change the type of the parameter in the receiving function from "whatev param" to "whatev& param". No need to change the call sites, or any of the function body.

Seems nice at first, but think about it from the perspective of a programmer who is calling a bunch of functions, and some of these functions may change the values he passes to them. Which ones may be changed? In C, it's obvious: anything passed as a pointer may be changed (through the pointer), but a non-pointer is always passed as a copy, so if you don't see a * in your call site, you're safe. In C++, it's impossible to tell without further context: any parameter passed to any function is potentially subject to mutation, until you confirm that it is not in fact passed by reference, by checking the type signatures of every single function you call. Pretty irritating!

PalmTreeFun posted:

Alright, you got me. I always just personally handled it the way C does, but I suppose when you're working with other people's code (which happens a lot more outside of college) it really does sound like kind of a dick move.

JewKiller 3000 posted:

JewKiller 3000 posted:

[pointers vs references]

seiken posted:

I kind of agree in principle but really references are an awesome language feature and IDEs these days should totally be able to pop up a signature with the &s there for you to see as soon as you type the (

Sedro posted:

Java has strange auto-(un)boxing rules.

Sedro posted:

Java performs this implicit conversion that could fail with an exception, without even raising a compiler warning.

Aleksei Vasiliev posted:

Eclipse warns me

JewKiller 3000 posted:

No. [...] Use of the term to mean something ostensibly similar, but actually with very important differences, is absolutely a horror; not only is it wrong, but the wrongness is masked by an explanation that sounds plausible to non-experts, encouraging them to also be wrong.

ToxicFrog posted:

I don't understand why you start with "no" when you're agreeing with me.

Beef posted:

For the love of god I will punch you if you pass everything around in C++ by reference because 'it makes it go faster'. I've seen people pass integers around using that reasoning...

Aleksei Vasiliev posted:

that's why you never use Integers or the other boxing classes if you can't help it
and also never use things written by idiots who return null Integers
Eclipse warns me

Zombywuf posted:

So, apparently this thread hates functions that mutate their arguments.

lol

And I really mean that, I did lol.

BonzoESC posted:

I hate mutation, and usually find myself writing Ruby similar to how I write Erlang: lots of non-mutative transformations to old objects into new variables. I'm pretty sure it absolutely chews up heap space and adds more to each GC load, but it also keeps me sane, reduces side effects, and makes it easier to test.

Ithaqua posted:

C# has nullable value types, but you have to explicitly specify that they're nullable. It's useful for, say, databases, where you could end up with a NULL integer coming back.

Zombywuf posted:

So, apparently this thread hates functions that mutate their arguments.

lol

And I really mean that, I did lol.

MEAT TREAT posted:

Ding ding ding. This is why Null Integers are useful.

Look Around You posted:

I don't hate it but I like knowing whether or not calling a function will change it's arguments. That's the big thing about it for me.

Sedro posted:

In C++ you can declare arguments as references and change their values. There is nothing like this in Java. Everything is passed by value, including references. In C# you can pass by reference but you have to be explicit in the callee and caller.

I guess you're asking for a way to make a mutable object immutable. If you pass a java.util.Date to a method, that method can mutate the date. That's the contract provided by Date, who are you to say otherwise? C++ behaves the same way in this regard.

MEAT TREAT posted:

Wait so in C++ you can pass a function a reference and then not be able to mutate it's field through that reference?

MEAT TREAT posted:

Wait so in C++ you can pass a function a reference and then not be able to mutate it's field through that reference?

haveblue posted:

Yes, you can use the const keyword to make the compiler enforce that.

Look Around You posted:

Also a lot of people writing Java think that AnObject x = new AnObject(); AnObject y = x; means that y gets a copy of the object x instead of becoming a copy of the reference to x which is pretty bad too.

Eggnogium posted:

...if you have this misconception out in the real world you're basically guaranteed to write horribly, horribly broken code...

JewKiller 3000 posted:

Dereferencing a NULL pointer leads to the ubiquitous segmentation fault.

haveblue posted:

Yes, you can use the const keyword to make the compiler enforce that.

feedmegin posted:

But the function can use const_cast to make it modifiable again. It's basically silly to try and 'force' a C++ library not to do $thingyoudontlike like this. Trust the library not to do something you dislike, or write a new library.

Eggnogium posted:

I have a hard time believing that. First-year CS students sure, but if you have this misconception out in the real world you're basically guaranteed to write horribly, horribly broken code unless you're exclusively consuming immutable types.

Beef posted:

Compilers are smart enough these days to figure out for themselves if objects really need to be copied or not.

ctz posted:

No it doesn't. The behaviour is undefined.

PraxxisParadoX posted:

php:

<?
    $a = "sock" . posix_getpid();
    $socket = "$a";
    $$a = $sock;
...
    socket_write($$socket, $msg, strlen($msg));
?>

From a "server". It's not the worst code in the "server" either.