Can you please elaborate?
* I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, it will go on the stack and won't add work for the garbage collector.
If you have an array of these, each element in the array will be a reference/pointer to a separately allocated Point instance which can be anywhere in the heap. Accessing the array is expensive due to lack of locality (arbitrary memory access). Additionally, each instance has substantial object overhead (typically 8 or 16 bytes).
There are various ways to deal with this. One way is to have separate arrays for x and y. Another way is to use a byte array and use Unsafe to read/write the integers. This is terrible from a developer standpoint and is only acceptable if it is a small part of your application.
Value types solve this by giving you an efficient memory layout while still allowing you to code against them as normal. The slogan is "codes like a class, works like an int".
class B {
A a1;
A a2;
}
Lack of value types makes it hard to get cache efficient memory layouts in Java.
Also an interesting aside is that objects are never 'allocated on the stack'. As in you won't find the same layout of memory on the stack as you do on the heap. Instead objects are turned into data edges in the compiler's graph. It's much more abstract than literally doing an alloca.
That's not quite correct. A reference type might contain a value type field, in which case the value type will still live on the heap.
Conversely, a local variable's type might be a value type, and _still_ involve a heap allocation. For example, std::vector in C++ is a value type but the array storage is heap-allocated.
So it's really about semantics, and not memory layout. Accessing an lvalue with a value type produces a copied rvalue; with reference types you're only copying the reference itself.
This isn't correct. Firstly, C++ doesn't have value or reference types. Where any object is stored depends purely on how it is allocated. Either in the free store (dynamic) or automatic storage (the stack).
std::vector has a constant object size - typically the size of 3 pointers (but that depends on the implementation - the standard doesn't specify): the start of the memory (dynamically allocated for storage), end/capacity (typically either another pointer or a size_t of the current capacity), and back (typically either a pointer just past the last element used or a size_t + 1 of current size). It's storage is dynamically allocated, though, and for a std::vector<T> will have dynamically allocated sizeof(T) * capacity bytes (maybe more due to alignment issues).
std::array is constexpr safe and does not (directly) dynamically allocate memory - size has to be known at compile time (hence it's a template argument).
For instance, on my compiler (GCC 4.8.4), for this example program:
#include <iostream>
#include <vector>
#include <array>
int main()
{
std::vector<int> v_ten(0, 10);
std::vector<int> v_twenty(0, 20);
std::array<int, 10> a_ten{0};
std::array<int, 20> a_twenty{0};
std::cout << "sizeof(v_ten): " << sizeof(v_ten) << std::endl;
std::cout << "sizeof(v_twenty): " << sizeof(v_twenty) << std::endl;
std::cout << "sizeof(a_ten): " << sizeof(a_ten) << std::endl;
std::cout << "sizeof(a_twenty): " << sizeof(a_twenty) << std::endl;
return 0;
}
sizeof(v_ten): 24
sizeof(v_twenty): 24
sizeof(a_ten): 40
sizeof(a_twenty): 80
The mention of array in the parent was referring to the dynamic storage of a vector, not std::array.
This was inherited from Smalltalk. Everything was an "object reference," with tag bits and all, but SmallInteger was optimized by using the low 16 bits of the object reference pointer to store the SmallInteger. So you can think of Smalltalk as having SmallInteger as a "primitive" type with pass by value.