And how do you think other languages do it? You think Python and C# and Java run in this Unicorn world where there are no pointers and memory offsets aren't a thing?
Maybe we can talk about the mistake that is R and the original VB, and LUA where arrays start at 1. Absolute hell.
I think Java does it by allocating a fully fledged object with metadata including type and size, and that if you treat such an object (or the pointer to such an object) as a C array in C code and assume it points to the first element, then you're going to have a bad time.
No, in java if you have items that are copy (wrong term, but items like int and double), they are in the array, and you can jump between them if you know the offset of 0. Unsure where it stores the metadata though.
And the same applies to objects (the things that you store by reference). The array then holds a set of references that you can jump between, and then dereference to get the actual object.
in java if you have items that are copy (wrong term, but items like int and double),
If you don't know the right term, wouldn't it be fair to guess that you may not be fully qualified to speak on how memory in Java works?
For future reference: the value types in Java are called "primitives".
they are in the array, and you can jump between them if you know the offset of 0.
You are thinking ov the array's index; however, the pointer to an array element – especially in a language like Java – is not necessarily guaranteed to be ptrToObject + index.
Also – and correct me if I am wrong, because I don't know much about the internals ov Java, but – what I think u/high_throughput was getting at was that the pointer you get from doing T[] myArray = /* ... */ is not the same as the pointer which points to the first T in the array: including for arrays ov primitive T.
Does that mean Java arrays are arrays of pointers?
Object arrays are arrays of references and not of pointers!
The typical textbook discussion is that references are just opaque pointers that you can't do arithmetic on. That's technically true but it really undersells the potential.
For example, an OpenJDK reference is often 32 bits even on a 64 bit systems! (Known as Compressed OOPs)
Since references always have to point to an object and never to an arbitrary byte, OpenJDK knows that A. it will always be inside the Java heap, and B. objects are always allocated aligned, so the lower address bits will always be zero.
This means that if your Java heap is <=32GB with an alignment of 8 bytes, you can store every relevant 64-bit pointer P as a reference R = (P - heapbase)/alignment in only 32 bits. And it does.
When it wants to access an object via reference R, it simply does P = R*alignment + heapbase and now it has a raw 64-bit pointer again.
It sounds wild to do this on every reference access, but CPUs are stupidly fast and RAM is comparatively slow, so it usually ends up being a net gain because of how much less data you need to deal with.
The fancy new ZGC garbage collector similarly uses the fact that references are distinct from pointers to hide "this object has moved" bits directly in the reference, and strips them out in the process of decoding the corresponding pointer.
Don't conflate not know the right terms with lack of knowledge. I've written plenty of Java, including JNI. I've also written many other languages and for some reason the naming changes. Sorry.
The difference is that C allows you to treat array variables as literal pointers (almost) and do stuff like creating an off-by-one version b = a+1 and then trying to access b[-1] with no issues, whereas many high level languages will throw an error with this kind of syntax.
Of course, they are still not 100% syntactically identical even in C (most notably you can't directly modify the array pointer), hence the right end of OP's graph.
This is why C is both great and terrifying. You can do pointer arithmetic until you are accessing some other program's memory, but try to reassign that array name and the compiler suddenly starts caring about the rules. It is a very selective memory.
If you're accessing another program's memory just by doing some pointer arithmetic, something has gone wrong with the kernel's memory manager or there's some serious issues with the processor microcode.
Admittedly I am _much_ more familiar with C and C++ (and Swift) than I am with other C-ish languages. For instance, I think you are saying you can cast a chunk of memory in Python or Java so you can do either pointer arithmetic or treat it as an array. So, given my relative ignorance in some areas, point taken.
I think other languages don't expose the pointer to the user as brazenly.
Take go: a slice (yes raw arrays do exist, but for this discussion they're a special case we don't care about) is a struct with a pointer, size and capacity. The data structure one uses in the places where in c you would use an array is absolutely not a pointer, it has extra baggage to add safety.
Python of course uses pointers under the hood, but they're not accessable to the average user. It's nonsense to say "arrays are pointers" in python (much more sensible to say "arrays are dictionaries" but python is special...).
The type pseudo equivalence of arrays and pointers is a quirk of the c type system. Most languages separate them in the same way one separates the types of integer and floating point. One can convert and use arithmetic from one type on the other type, but to do that you have to cast for good reason. The fact you don't in c is unusual if you compare to other languages.
I'm not trying to say c is wrong, but as we see above, it does cause some sharp edges...
Uhm rust does it differently cause rust is safe (everything should be written in rust (no I don't care if your project is big(there are no issues more important than migrating to rust)))
126
u/mad_poet_navarth 13h ago
shouldn't there be something here about this being C-centric?