Roedy Green sez:
With 1.5 autoboxing you can, even if it is implemented with objects.
Further, you can easily write analogs of ArrayList, HashMap, and
HashSet that hold primitives. People imagine there must be some black
magic that makes these classes work. The guts are very simple and you
can study the source in src.jar/src.zip for the object version. In the
old days everyone wrote these classes for themselves. Read
http://mindprod.com/jgloss/hashtable.html for example to help
understand how hashed lookup works.
You keep coming across like some helpless newbie who imagines if the
class does not exist prewritten there is some insurmountable obstacle.
C++ has a slight advantage in writing such code because you can, for
example, store pairs of ints at each slot in an array. With Java, you
need two separate arrays indexed the same, or you need to store a
reference to an object containing a pair at each slot. But you
strongly exaggerate when you state that Java can't tackle the same
problems quite efficiently. The java code is slightly less convenient
to write but it runs more efficiently since indexing does not require
multiplication, just shifts which can sometime be done free.
You keep coming across like someone with reading comprehension
skills of a doorpost and attention span of an amoeba.
ArrayList does array copy for resizing. Whether I look at src.zip
or not, it still does array copy.
You said it yourself: that is unsuitable for large dataset/low
memory situations because it requires twice the memory.
C++ has a "slight advantage" in that you can use realloc(3) to grow
your array in situ, no array copy required.
This whole discussion started because someone suggested replacing
container objects with arrays of primitive types to store large
datasets.
(The keyword here is _primitive_types_, so 1.5 autoboxing is no use
_because_ it is implemented with objects, BTW.)
You said that right way of using arrays is to count the values first
and create array of the correct size. I added that this doesn't work
in a general case where number of elements is not known in advance;
in addition, retrieveing array elements based on value rather than
array subscript is inefficient, so you'd need to also write your own
lookup tables etfc.
"The Java code" to implement lookup tables, make sure your arrays
never get out of sync, etc., "is slightly less convenient to write"
only for very large values of "slightly".
C++ has a "slight" advantage in that you can use vectors to store
your datapoints regardless of their data type. (Ever heard the
phrase "first class citizens" applied to user-defined data types?
That's what OO languages other than Java do.)
The fact that you can store pairs in arrays is _not_ an advantage
of C++: you can store pairs in Java arrays too. The only difference
is that pair comes standard in C++; in Java you need to define it
yourself.
The problem, again, is having too many objects in your Java program.
That's why you want to store your pairs in two arrays instead of a
Pair []. (And then you need to make sure your two arrays never ever
get out of sync, and that makes your Java code "slightly less
convenient to write"... but I already said that.)
And by the way, array indexing in C++ does not necessarily
require multiplication: '*' in "*a + elt_num" is _not_
a multiplication sign, appearances notwithstanding .
Dima
