From: Niklas Matthies on
On 2005-10-13 13:36, Virtanen Antti wrote:
:
> Deriving a class MyInteger from built-in class Integer could also
> present a performance problem for arrays containing
> Integer-instances. Array of primitive ints is clearly a continuous
> block of memory containing 32-bit numbers while array of Integers
> should look like an array of "real" objects where the objects could
> be either from the MyInteger or Integer. Oops, no more easy and fast
> memory (de)allocation with zero space overhead. Of course, this
> could be prevented by making Integer a "final" class, but this might
> prevent some reasonable use of Integer-class.

Indeed, and java.lang.Integer actually is final (also java.lang.String
and other such "basic" types). The problem with arrays is that any
array of type T[] can be aliased by a reference of type S[] when S
is a supertype of T; e.g. an Integer[] can be aliased by an Object[].
That means that either the array must actually contain object
references, or else array accesses have to be dynamically dispatched
depending on the dynamic element type, which can be even worse for
performance.

> This is going quite offtopic, so perhaps better end it :) Anyway, C++
> might some day have reflection and auto(un)boxing too or we might be
> using a language very similar to C++ which has these :)

Sounds like C++/CLI. ;)

-- Niklas Matthies

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: kanze on
Virtanen Antti wrote:
> On 2005-10-07, kanze <kanze(a)gabi-soft.fr> wrote:

> >> still holds: generics in Java discriminates against
> >> built-ins such as int or double.

> > Java discriminates against them in general. I never could
> > figure out why -- if every thing is an object, you define
> > the expression a + b to mean a.add( b ) (which means that
> > operator overloading is automatically implied). And count
> > on the compiler to do the necessary optimization if the type
> > of a and b is just a wrapper for int. (Note that Smalltalk
> > did this from the beginning, and that Smalltalk compilers
> > were actually doing this optimization before Java was
> > invented. So there's no excuse there, either.)

> I've been wondering the same thing. Original reason for the
> primitive types was "performance", which is quite
> obvious. However, as you said, Smalltalk had this already, so
> this sounds like an excuse.

To be honest, the contexts of Smalltalk and early Java are quite
different. As far as I know, the Smalltalk "interpreter" loaded
the entire program, and optimized that. Java loads class by
class, and thus cannot see all of the uses of a type or an
object -- this is important in order to decide whether you can
convert an array of Integer objects into what is really an
int[].

--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dave Harris on
kanze(a)gabi-soft.fr (kanze) wrote (abridged):
> > I've been wondering the same thing. Original reason for the
> > primitive types was "performance", which is quite
> > obvious. However, as you said, Smalltalk had this already, so
> > this sounds like an excuse.
>
> To be honest, the contexts of Smalltalk and early Java are quite
> different. As far as I know, the Smalltalk "interpreter" loaded
> the entire program, and optimized that.

No, most Smalltalk implementations can load classes dynamically. Also
Smalltalk handles integer overflow by switching to a larger kind of
integer, so in code like:
x := x + 1.

the type of x may change even if no new classes are loaded. The technology
developed for Self can make this kind of thing efficient, but it's not
easy. My understanding is that Gosling knew it was possible but didn't
quite have the nerve to rely on it. A bit like "register" in C.

Anyway, I think a better model would have been Eiffel. Eiffel has
user-defined value types so it can treat integers as objects, but as value
objects, and still keep a uniform system. It can express the difference
between these:

int array1[10]; // Array of int values.
int *array2[10]; // Array of int references/pointers.

Users can inherit from the Eiffel equivalent of int, and the derived type
can be stored in array2 but not in array1. So array1 remains efficient.

I think it is a shame the Java platform designers chose to invent a new
language rather than using an existing one. It was probably a good thing
for C++, though. Likewise with "D" and "C#".

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: C++/CLI limitations?
Next: SHA1