3 ms·

No. In Java every object variable is a reference type. They're all implicitly pointers. Hence why all objects can be null. Java just hides all the dereferencing

No. In Java every object variable is a reference type. They're all implicitly pointers. Hence why all objects can be null. Java just hides all the dereferencing away. "Object myobject;" creates a pointer/reference rather than an actual object. In C++ you can have pointers to objects, but they're explicitly denoted by an asterisk. The C++ equivalent would be "Object* myobject;" However, you can also directly have object variables in C++. That's not something that exists in Java. A variable declared like, "Object myobject;" can never be null. The myobject variable is a value, just like i in "int i = 5;" is a value.

repsilat 8y ago
To expand on this: In C++ a useful heuristic could be to think of values like Java primitives. A C++ integer takes up some amount of space. Maybe it's four bytes on your platform. Integers on your platform take up four bytes. Not "four bytes plus a pointer", but four bytes and that's it. In those four bytes you can store 2^32 values. There's nowhere else to store whether the integer is null -- if you wanted to signal to someone that the value was "missing", you would either have to, - Come up with your own "in-band" signal, like "-(2^31) means 'missing'", or - Have an out-of-band signal, like a separate boolean variable, or keep a pointer to "integer or null". (Pointers being nullable is arguably kinda weird still.) Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) Again, there's nowhere to signal that the value is missing -- if you don't fill in that memory location or that register, well, there will just be some other (undefined) value sitting in its place that the caller will read. Ditto functions that expect integer arguments etc. Now, this has some interesting consequences: for stack-allocated values in C++, "object identity" tends to be preserved less often than in Java. When you put an object into a `vector`, you'll probably put a copy there. When you mutate that copy or call some function on it, you're not mutating the original. You can get back to "Java semantics" of object identity and nullability etc by using pointers and explicit heap storage.
- cesarb 8y ago
  > Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) On a register. I don't know of any mainstream platforms which return simple values like an integer through the stack. For larger values (larger than a word or a couple of words), on the other hand, usually the calling function passes the called function a pointer to a location on the stack where it should write the result. Either way, like you said "there's nowhere to signal that the value is missing".
  - kupiakos 8y ago
    Nitpicky detail: a lot of the time, the pointer variable passed to be written to is not on the stack, e.g. using strcpy with a malloc'd buffer.
    - mianos 8y ago
      I believe he is taking about the native retuning semantics, which is in a real register for simple types or organised to be on the stack by the caller or register frame for a larger value type. Point being, it's a compact primitive reflection of the machine, not much more.
jcrites 8y ago
C++ also has references, which are like pointers in some ways, except that references cannot be null: Object& obj = other_obj; For this reason, when passing objects by reference, references should be preferred to pointers where possible. Consequently, I would translate Java code like: void f(Object obj) { ... } Object obj = ... f(obj); Into C++ code like: void f(Object& obj) { ... } Object& obj = ... f(obj); (Setting aside various other concerns like move semantics and const-correctness.)
- Koshkin 8y ago
  A nice thing about references (to classes) is that you can use the dot and not the silly arrow which I don't know why exists in the first place.

repsilat 8y ago

To expand on this: In C++ a useful heuristic could be to think of values like Java primitives. A C++ integer takes up some amount of space. Maybe it's four bytes on your platform. Integers on your platform take up four bytes. Not "four bytes plus a pointer", but four bytes and that's it. In those four bytes you can store 2^32 values. There's nowhere else to store whether the integer is null -- if you wanted to signal to someone that the value was "missing", you would either have to, - Come up with your own "in-band" signal, like "-(2^31) means 'missing'", or - Have an out-of-band signal, like a separate boolean variable, or keep a pointer to "integer or null". (Pointers being nullable is arguably kinda weird still.) Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) Again, there's nowhere to signal that the value is missing -- if you don't fill in that memory location or that register, well, there will just be some other (undefined) value sitting in its place that the caller will read. Ditto functions that expect integer arguments etc. Now, this has some interesting consequences: for stack-allocated values in C++, "object identity" tends to be preserved less often than in Java. When you put an object into a `vector`, you'll probably put a copy there. When you mutate that copy or call some function on it, you're not mutating the original. You can get back to "Java semantics" of object identity and nullability etc by using pointers and explicit heap storage.

cesarb 8y ago
> Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) On a register. I don't know of any mainstream platforms which return simple values like an integer through the stack. For larger values (larger than a word or a couple of words), on the other hand, usually the calling function passes the called function a pointer to a location on the stack where it should write the result. Either way, like you said "there's nowhere to signal that the value is missing".
- kupiakos 8y ago
  Nitpicky detail: a lot of the time, the pointer variable passed to be written to is not on the stack, e.g. using strcpy with a malloc'd buffer.
  - mianos 8y ago
    I believe he is taking about the native retuning semantics, which is in a real register for simple types or organised to be on the stack by the caller or register frame for a larger value type. Point being, it's a compact primitive reflection of the machine, not much more.

jcrites 8y ago

C++ also has references, which are like pointers in some ways, except that references cannot be null: Object& obj = other_obj; For this reason, when passing objects by reference, references should be preferred to pointers where possible. Consequently, I would translate Java code like: void f(Object obj) { ... } Object obj = ... f(obj); Into C++ code like: void f(Object& obj) { ... } Object& obj = ... f(obj); (Setting aside various other concerns like move semantics and const-correctness.)

Koshkin 8y ago
A nice thing about references (to classes) is that you can use the dot and not the silly arrow which I don't know why exists in the first place.