C++ Concepts
in [C++]
|
Prev: C++/CLI limitations?
Next: SHA1
From: Niklas Matthies on 13 Oct 2005 18:58 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 14 Oct 2005 13:27 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 16 Oct 2005 05:39
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! ] |