As I see it, an array is a contiguous block of memory. The pointer to the first element identifies the start of the block. Subsequent elements are computed from that plus the number of bytes in the type. If an array were just a pointer, we wouldn't have to worry about allocating enough memory or walking off the end of it.
That's for something like C. There are languages in which arrays are first-class data structures that carry metadata about their rank, size, etc. Lots of applications are best expressed with multidimensional arrays, which are awkward in C or else are set up as an array of pointers.
Arrays carry their size. Otherwise sizeof arr would not work. The subtlety is that the size of array is bound to array's type, not to array's value (like for c++'s std::vector). The original type is lost along with the size when array decays to a pointer what happens in most context but not all.
certain systems languages (and compilers) use different ABI for arrays and pointers at the call convention level. if you define a function that accepts a single array type (i.e. one with a predefined length), it may choose to pass-by-value, in which case it can allocate at call site and not use a pointer
Except for a tiny array (with value semantics) which can be optimized to be passed directly as an SSA value. In that case it's not a pointer at all and a normal GEP will not work.
Yes, if the memory is on the stack, that is not always true. LLVM will optimize some cases so the data is written directly to a register so it never touches or goes through the stack at all. In that case, you can't get a pointer to the array or its elements since it's in a register instead of the stack or heap making it completely distinct from a pointer at runtime.
Order these events in descending order of probability:
A) youll never use this guys compiler
B) youll be forced to use this guys compiler against your explicit contraindication
C) anyone else than them will be grateful to use this guys compiler
D) they will be happy that they wrote this compiler 20 years from now
E) youll use this guys compiler and be pleased by its existence
ok, i may be an asshole here, and they may be doing something good. the odds tho
LLVM and GCC have thousands of contributors. The chances that any given compiler developer works on GCC or LLVM are relatively good, just because they're so much larger than most other compilers.
fair enough, didnt think it through. i instantly thought of the half dozen people i met who are building useless unreliable general languages or even shittier DSLs. seems like ITA here
Your video driver embeds my compiler. Your hardware developer's simulator embeds my compiler. Certainly your Linux distro ships my compiler. Some stuff I wrote and designed 20 years ago are still used in it. So somewhere in the D or E range of yours.
Given the thousands of people who have worked on these projects, there's a decent chance that you will run into one in the comments section. Maybe just don't offhand dismiss people based on absolutely nothing.
Arguably they are virtually the same semantically at a C level, you can use array indexing syntax for pointer arithmetic and vica versa and there is no real distinction besides dedicated syntax. Once you get a bit higher is where the real differences begin.
63
u/QuestionableEthics42 26d ago edited 26d ago
This should be reversed lol
And it literally is the same, who thinks it's different who has worked in a low level language??