Earlier quoted context omitted.
I believe that comma thing was added recently.
[flagged]
Inside the JVM: Arrays and how they differ from other objects
71–80 of 133 posts
Re: Inside the JVM: Arrays and how they differ from other objects
#72> (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.) I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?
The article is very confused in general about multidimensional arrays (which are really just arrays of array references in Java). It’s badly written and IMO doesn’t deserve to be on the HN front page. The author seems to have expectations that Java multidimensional arrays violate, and seems to assume the reader would also have those expectations, but they just seem confused to me. Except for TFA’s mention of the byte…
"Arrays, however, have a property called length, which can be queried to get the number of elements in the specified array."
This is not correct and causes bugs. Length is the length of the array, not the number of elements within it. Maybe the author understands this, but precision of language is important here and as-written this is either ambiguous at best or incorrect at worst.
Also the entire section for "Array size and the concept of arrays of arrays" is terribly confused. Again I'm not sure if this is imprecise use of language or if the author is truly this confused about the topic, but:
"As you can see, what you have is truly three arrays, working together to create the equivalent of a three-dimensional array."
No, in the naive case of "new int[M][N][10]" you have 1 + M + MN arrays. And if you are working with only the type int[][][], just checking arr.length, arr[0].length, and arr[0][0].length will not give the the dimensions of the 3d array - any of the arrays can be of any length (the length of the array is not part of the type system).
And I feel like I'm not nitpicking here - note some algorithms, like DP ones for instance, only use a "diagonal" half of a 2d array and allocating the other half would be wasted space. So it's very possible you'll encounter such non-trivially-shaped 2 and 3D arrays in practice.
"Here’s an interesting question: What would happen in a multidimensional array if one of the dimensions were declared with a size of 0? For example,
strangePoints = new int[3][4][0][2]"
This was a TIL to me though, I'm kind of surprised this doesn't throw at runtime? But also, I suppose, not surprised. It's weird because, is int[3][4][0][2] really* an int[][][][]? I guess it's not not an int[][][][] but it's also kind of weird that it is. I guarantee this has caused a bug at some point. This would be a cursed interview question.
Re: Inside the JVM: Arrays and how they differ from other objects
#73Earlier quoted context omitted.
The article is very confused in general about multidimensional arrays (which are really just arrays of array references in Java). It’s badly written and IMO doesn’t deserve to be on the HN front page. The author seems to have expectations that Java multidimensional arrays violate, and seems to assume the reader would also have those expectations, but they just seem confused to me. Except for TFA’s mention of the byte…
To elaborate further, consider this quote from TFA: “ For example, strangePoints = new int[3][4][0][2] In this declaration, all dimensions after the zero-size dimension are ignored. So, the result of this declaration is equivalent to a two-dimensional array of ints. ” This is just plain wrong. It’s a four-dimensional array of ints, just one that cannot contain more than zero ints, because one of the dimensions is zer…
Re: Inside the JVM: Arrays and how they differ from other objects
#74> (Note that the comma after the last value is accepted in Java and won’t cause an error.) Why have I been 15 years programming in Java and I discovered this today? On a more serious note, I prefer this kinds of posts to the traditional "Look at this shiny new thing" because without fundamental stuff the next big thing can't be built and normally this information makes you a slightly better programmer.
Likely because it's inconsistent with all other parts of the language where trailing commas are not allowed
Why? Because whenever there's a new value added, git diff shows single line change :)
Re: Inside the JVM: Arrays and how they differ from other objects
#75Earlier quoted context omitted.
[flagged]
Did you ask yourself this question before you wrote this comment?
(I have now answered your question. If you respond, how about doing so in the form of an answer to mine—and not evading it with another question?)
Re: Inside the JVM: Arrays and how they differ from other objects
#76Earlier quoted context omitted.
Or it might be that the person has used multiple programming languages, across which the order/meaning of copy arguments varies a lot, and thus prefer to not remember the decision of each language (if not for writing (at which point the IDE could help), then for reading). Whereas a loop is always easy to read and write equally in all languages, and it's really not unreasonable to expect it to perform well enough (if…
Given that I have programed dozen of languages since 1986, and have to jump between C#, Java, C++, Typescript, Transact SQL and PL/SQL for work, plus whatever is needed to keep the customer happy, isn't an argument I would sympathise with in code reviews.
Re: Inside the JVM: Arrays and how they differ from other objects
#77Earlier quoted context omitted.
Does that bytecode do anything more efficient than allocating arrays inside of arrays inside of arrays etc? Does it ensure they’re contiguous? Does a multidimensional array allocated in this way still require pointer chasing to get to the values? It’s not really a helpful statement. Initializing a single flat array with stride metadata alongside gives you memory locality and arithmetic access. Intuitively, I wouldn’t…
Well, /u/aardvark179 claimed that the JVM did not treat multidimensional arrays in any special way at all, i.e. that it is completely just a composition of features already available in the JVM, but that was wrong, since multidimensional arrays have their own special bytecode. Anything beyond that is irrelevant, I'm just correcting his mistake there.
Re: Inside the JVM: Arrays and how they differ from other objects
#78Earlier quoted context omitted.
Given that I have programed dozen of languages since 1986, and have to jump between C#, Java, C++, Typescript, Transact SQL and PL/SQL for work, plus whatever is needed to keep the customer happy, isn't an argument I would sympathise with in code reviews.
Yet, somehow I doubt you write perfect code in all those languages. Do you cringe at yourself and conclude you just don’t care also?
Re: Inside the JVM: Arrays and how they differ from other objects
#79> (Note that the comma after the last value is accepted in Java and won’t cause an error.) Why have I been 15 years programming in Java and I discovered this today? On a more serious note, I prefer this kinds of posts to the traditional "Look at this shiny new thing" because without fundamental stuff the next big thing can't be built and normally this information makes you a slightly better programmer.
Likely because it's inconsistent with all other parts of the language where trailing commas are not allowed
function foo(x,) {}
def foo(x,): pass
Before anyone questions why anyone would do this, it's for putting arguments (or array elements) on separate lines: function foo(
a,
b,
c,
) {}Re: Inside the JVM: Arrays and how they differ from other objects
#80Earlier quoted context omitted.
Well, /u/aardvark179 claimed that the JVM did not treat multidimensional arrays in any special way at all, i.e. that it is completely just a composition of features already available in the JVM, but that was wrong, since multidimensional arrays have their own special bytecode. Anything beyond that is irrelevant, I'm just correcting his mistake there.
OK, so they're treated in a special way that's completely irrelevant to the concerns one might have when using multidimensional arrays. It's just an implementation detail with no practical considerations.