[Java/.NET] primitieve datatypes

[whoami]

Om een ander topic maar niet off-topic te brengen, even een ander topic.

In dat topic maakte ik de opmerking dat in .NET alle data-types (dus ook de primitieve) objecten zijn en in Java dit niet het geval is.
Nu repliceerde mbravenboer daarop dat dit niet waar is, nochtans heb ik in de .NET help nog eens gekeken en daar zie ik toch wel degelijk staan dat alle data-typen (zowel value als reference) afgeleid zijn van het type 'object'. En aangezien object een class is, impliceert dit dat al deze datatypen ook objecten zijn.

Sla ik de bal hier nu mis? Zoja, waar sla ik hem mis, of zijn primitieven in Java ook objecten?

[Verwijderd]

mbravenboer kan het vast beter uitleggen, maar volgens mij werkt .NET intern wel met primitieven en de object(wrappers) van de primitieven. Een primitieve is dus een primitieve (en geen object) als dat niet nodig is (om performance redenen) en een object als je hem/haar ( ) zo behandelt, dit gaat zoals je weet dmv boxing.

Het is dus meer dat Microsoft je het gevoel wil geven dat er geen echte (niet object) primitieven bestaan, door boxing onmerkbaar te laten verlopen.

Ofzo

[Tuinhark]

Mee eens.

[mbravenboer]

Een java.lang.Integer en een java.lang.Boolean zijn ook afgeleid van java.lang.Object, dus dat zegt niet zo heel erg veel.

.NET voert op zich wel een verbetering in, maar het is een te gemakkelijk stap die volgens mij zelfs nog wel wat nadelen kan hebben. In .NET wordt er op een redelijke efficiente manier naar behoefte een object gemaakt van een primitieve. Dit zorgt er dus niet voor dat de primitieven ook objecten zijn, maar dat je ze als objecten kan gebruiken als je dat wilt. Van deze conversie merk je natuurlijk niets, maar toch is er nog steeds een scheiding tussen de twee werelden.

De redenatie van mij (en velen in het programmeer talen onderzoek) is dat de 'primitieven' een optimalisatie detail zijn waarmee je je taal sowieso al niet moet vervuilen. Dat bekende objecten efficient gecompileerd kunnen worden zou namelijk een taak voor de compiler moeten zijn. Deze kan door analyse het gebruik van objecten vervangen door 'primitieven'. Deze optimalisatie hoeft dan ook niet alleen voor de bekende ints, boolean en longs te gebeuren, maar kan voor alle klassen en alle situaties gebeuren. Dit zou veel van de performance problemen in Java (en in het bijzonder in Swing) oplossen.

Het gebruik van primitieven en de object tegenhanger daarvan onstaat zo niet uit een noodzaak (als er een methode wordt aangeroepen op een integer bijvoorbeeld), maar uit een afweging: wat is efficienter (en vooral: wat is mogelijk) in een bepaalde situatie?

Autoboxing ziet er vanaf buiten hetzelfde uit, dus als je niet zo geinteresseerd bent in de opbouw van een taal zal het je weinig interesseren of er nu een autoboxing of een analyse oplossing gekozen is in een taal . De performance consequenties van autoboxing zouden echter in sommige situaties weleens vervelend (en ondoorzichtig) kunnen zijn. Ik heb helaas nog niet de gelegenheid gehad om hier worst-case scenario's voor te zoeken en heb ook nog goede voorbeelden op het web gezien.

[whoami]

Met het principe van boxen ben ik bekend, idd.... Maar, als ik het dan goed begrijp, dan is een integer bv in .NET toch niet afgeleid van 'object', terwijl er toch in de help staat dat alle value - en reference types inheriten van object.

[mbravenboer]

zie ook deze post:
[rml]mbravenboer in "[ Java] Object vs primitieve"[/rml]

en deze pagina:
[rml][ JAVA] operator overloading gefaked?[/rml]

[Glimi]

Misschien zegt wat code meer.

C++:

int theInt = 0;
theInt.ToString();

Zals door C# imho bij het compileren omgezet worden naar de volgende code

C++:

int theInt = 0;
Integer tempInteger = new Integer( theInt );
tempInteger.ToString();

Tja, dan zitten er toch nog primitieven in C#, alleen jij benadert ze niet meer zo

[kenneth]

Tja, uiteindelijk zijn het allemaal enen en nullen, dus dan is niets een object

Maar als je op programmeerniveau een primitief transparant als een object kan benaderen, is het imho gewoon een object en geen zuivere primitief.

[Verwijderd]

mithalph schreef op 19 November 2002 @ 16:24:
Maar als je op programmeerniveau een primitief transparant als een object kan benaderen, is het imho gewoon een object en geen zuivere primitief.

Dan heeft men haar doel dus bereikt

[JohanDM]

Alhoewel de objecthierarchie doet geloven dat een primitief type erft van ValueType die erft van Object, is dat enkel in de boxed toestand van de primitief waar.
Zolang de primitief niet geboxed is, is het een echte/zuivere primitief zonder object franje eraan. Dit kan gemakkelijk gecheckt worden met ILDASM, dan zie je zo het verschil tussen geboxte en niet geboxte primitieven, tenminste als je iets van IL assmbly kent.
Het is de compiler die ervoor zorgt dat primitieven die als object gebruikt worden geboxt worden. Dus als je met zuiver primitieven wil werken, gebruik ze dan in code niet als object, en de compiler zal netjes echte/zuivere primitieven afleveren.

[kenneth]

Waar ligt de grens? Zoals ik aangaf, bestaat op een gegeven moment het begrip "object" ook niet meer.
Zo kan je zelfs van Smalltalk zeggen dat het niet OO is, of dat Java wél de goto-statement ondersteunt (uiteindelijk wordt het via de JIT toch een "jne 0x1351").
Op programmeerniveau is een getal een object, en geen primitief. Ik neem aan dat de (un)boxing volledig transparant is? _Toch?

[bazzs2001]

whoami schreef op 19 november 2002 @ 15:45:
Om een ander topic maar niet off-topic te brengen, even een ander topic.

In dat topic maakte ik de opmerking dat in .NET alle data-types (dus ook de primitieve) objecten zijn en in Java dit niet het geval is.
Nu repliceerde mbravenboer daarop dat dit niet waar is, nochtans heb ik in de .NET help nog eens gekeken en daar zie ik toch wel degelijk staan dat alle data-typen (zowel value als reference) afgeleid zijn van het type 'object'. En aangezien object een class is, impliceert dit dat al deze datatypen ook objecten zijn.

Sla ik de bal hier nu mis? Zoja, waar sla ik hem mis, of zijn primitieven in Java ook objecten?

Volgens mij is in C# (rest van .NET weet ik niet) alles een Object dus ook de integers.

in java heb je nog wel primitieven (die moeten ze er IMHO ook uitgooien) een int is bijvoorbeeld een primitieve, ik vind dat ze het in java moeten doen zoals ze al met Strings doen wel operators als + en - maar toch Objecten (kan je ze bijvoorbeeld ook zonder moeite in een Vector gooien).

[whoami]

[nohtml]

bazzs2001 schreef op 20 november 2002 @ 11:33:
[...]

Volgens mij is in C# (rest van .NET weet ik niet) alles een Object dus ook de integers.

Als het in C# zo is, dan is het in de rest van het framework ook zo.
Maar, het is blijkbaar zo niet in C#. Een int is geen object, terwijl een Integer dat wel is.
Volgens het geen ik er nu van versta is, dat als je in C# het volgende doet:

code:

int i = 5;
MessageBox.Show (i.ToString());

Dat die i die van het type int is (en dus een primitief is), automatisch door het framework geboxed wordt naar een object van het type Integer (Integer is een class afgeleid van object).

Dus, voor de programmeur lijkt het wel dat int een object is, maar eigenlijk is dat niet zo. Een primitief wordt automatisch geboxed naar de overeenkomstige class.

[Orphix]

Dat alles transparant gebeurt in C# heeft voordelen en nadelen.
Een voordeel is dat je integers altijd kan behandelen als objecten terwijl ze intern toch, indien mogelijk, als primitieven worden behandeld.
En dit is ook een nadeel, wanneer gebeurt dit, wanneer gaat dit ten koste van de performance? Stel je stopt allemaal integers in een List, worden dit dan objecten? En in de toekomst met generics, slaat een List<int> dan wel puur primitieven op?

Het is allemaal wat minder duidelijk wat je doet maar dat is de trade-off denk ik. Primitieven eruitgooien is simpelweg geen optie, ik hoop niet dat mijn iteratie integer in een for-loopje een constructor/destructor heeft en door de GC opgeruimt moet worden ...

[bazzs2001]

whoami schreef op 20 november 2002 @ 11:36:
[nohtml]
[...]

Als het in C# zo is, dan is het in de rest van het framework ook zo.

Dat hoeft toch niet? Het wordt toch gecompiled? De compiler kan het dan intern omzetten naar een primitief type

Maar, het is blijkbaar zo niet in C#. Een int is geen object, terwijl een Integer dat wel is.
Volgens het geen ik er nu van versta is, dat als je in C# het volgende doet:

code:

int i = 5;
MessageBox.Show (i.ToString());

Dat die i die van het type int is (en dus een primitief is), automatisch door het framework geboxed wordt naar een object van het type Integer (Integer is een class afgeleid van object).

Dus, voor de programmeur lijkt het wel dat int een object is, maar eigenlijk is dat niet zo. Een primitief wordt automatisch geboxed naar de overeenkomstige class.

Ik ben niet zo thuis in C# maar als je net als in Java een klasse Vector hebt waar je Objecten in kan zetten kan je daar dan ook een "int" inzetten (en hoef je er niet eerst zelf zoals in java een Integer van te maken).

En als het lijkt op een Ojbect, gebruikt wordt als een Object en overerft van een Object (hier kan ik me dus vergissen voor C#) is het dan niet gewoon een Object?

[whoami]

bazzs2001 schreef op 20 November 2002 @ 12:41:
Ik ben niet zo thuis in C# maar als je net als in Java een klasse Vector hebt waar je Objecten in kan zetten kan je daar dan ook een "int" inzetten (en hoef je er niet eerst zelf zoals in java een Integer van te maken).

In .NET gebeurt dat dus automatisch. (Autoboxing).

En als het lijkt op een Ojbect, gebruikt wordt als een Object en overerft van een Object (hier kan ik me dus vergissen voor C#) is het dan niet gewoon een Object?

Idd. Maar een int erft niet over van object. De class Integer wel, maar int is hier een primitief en Integer niet. Het framework gaat er wel voor gaan zorgen dat een int gemapped (geboxed) wordt naar een Integer indien dat nodig is.

[Alarmnummer]

bazzs2001 schreef op 20 november 2002 @ 12:41:
[...]
Ik ben niet zo thuis in C# maar als je net als in Java een klasse Vector hebt waar je Objecten in kan zetten kan je daar dan ook een "int" inzetten (en hoef je er niet eerst zelf zoals in java een Integer van te maken).

C# die plaatst daar ook een object in, maar door autoboxing heb je dat niet altijd in de gaten. (Dit is ook meteen een van de argumenten tegen autoboxing: performance problemen worden over het hoofd gezien).

ps:
kan je trouwens in C# met generics dit ook zeggen?
Vector<int> ?
Dus parametrisatie met een primitieve?

[Creepy]

WAt ik me afvraag is hoe je zonder primitieven toch objecten kan definieeren? Als je begint met een base klasse, en deze wilt gaan uitbreiden, hoe doe je dat dan zonder primitieven? Dan moeten er toch in een framework een aantal objecten al bekend zijn. Maar waaruit bestaan deze dan? Niet uit primitieven, want die heb je niet. Maar waaruit bestaan die objecten dan? etc. etc.

(kip/ei probleem). Hoe definieer je een object als je geen andere objecten of primitieven hebt.

[bazzs2001]

whoami schreef op 20 November 2002 @ 12:50:

[...]

In .NET gebeurt dat dus automatisch. (Autoboxing).


[...]

Idd. Maar een int erft niet over van object. De class Integer wel, maar int is hier een primitief en Integer niet. Het framework gaat er wel voor gaan zorgen dat een int gemapped (geboxed) wordt naar een Integer indien dat nodig is.

ok dan sluit ik me erbij aan dat het geen object is

[whoami]

Alarmnummer schreef op 20 november 2002 @ 12:50:
[...]


ps:
kan je trouwens in C# met generics dit ook zeggen?
Vector<int> ?
Dus parametrisatie met een primitieve?

Voor zover ik gelezen heb in dat artikel over de 'new language features': ja.
(Trouwens, ik denk dat in dit geval int ook wel naar 'Integer' zal geboxed worden).

[Alarmnummer]

whoami schreef op 20 November 2002 @ 13:32:

[...]


Voor zover ik gelezen heb in dat artikel over de 'new language features': ja.
(Trouwens, ik denk dat in dit geval int ook wel naar 'Integer' zal geboxed worden).

Dat vermoeden heb ik ook. Ik denk dat dit allemaal goed gaat:

Vector<int> v = new Vector<int>();
v.add(new Integer(10));
int foo = v.get(0).intValue();

en dan gaat dit denk ik ook wel goed
Vector<int> v = new Vector<int>();
v.add(null);

[Verwijderd]

Alarmnummer schreef op 20 November 2002 @ 13:51:
[...]
en dan gaat dit denk ik ook wel goed
Vector<int> v = new Vector<int>();
v.add(null);

En nu krijgen we het nice verhaal weer neem ik aan?

[whoami]

Alarmnummer schreef op 20 November 2002 @ 13:51:
[...]


Dat vermoeden heb ik ook. Ik denk dat dit allemaal goed gaat:

Vector<int> v = new Vector<int>();
v.add(new Integer(10));
int foo = v.get(0).intValue();

en dan gaat dit denk ik ook wel goed
Vector<int> v = new Vector<int>();
v.add(null);

Hmmm..... Dat weet ik nog niet zo zeker....
Als je een template maakt van die class Vector voor het type int, dan kan je er enkel maar int's aan toevoegen. Ik denk niet dat 'null' converteerbaar is naar een int, tenzij dat dat toch '0' oplevert, of tenzij die ints naar Integer geboxed worden en 'null' in Integer wel toegestaan is.
Dat zullen we eens moeten testen, eens die generics beschikbaar zijn.

[Alarmnummer]

C# generics is iets anders dan c++ templates. Bij c++ wordt code gegenereerd op basis van de 'instantie' van die template en je kan daar dus ieder type in stoppen. Deze aanpak is bij c++ ontstaan omdat ze dus geen object based hierarchie hebben en er dus geen gemeenschappelijke supertype is

[bazzs2001]

Alarmnummer schreef op 20 November 2002 @ 13:51:
[...]


Dat vermoeden heb ik ook. Ik denk dat dit allemaal goed gaat:

Vector<int> v = new Vector<int>();
v.add(new Integer(10));
int foo = v.get(0).intValue();

werkt "int foo = v.get(0);"
niet gewoon, of moet je het na de declaratie zien als
Vector<Integer> i.p.v Vector<int>

(bazzs is toch wel geintreseert in C# ook al kan die het nog niet)

[ Voor 0% gewijzigd door bazzs2001 op 20-11-2002 15:53 . Reden: toevoeging ]

[Alarmnummer]

bazzs2001 schreef op 20 November 2002 @ 15:52:
[...]

werkt "int foo = v.get(0);"

Dat werkt ook wel door de autoboxing Maar ik denk als je het type opvraagt van v.get(0) dat daar wel een Integer staat, en niet een int.

niet gewoon, of moet je het na de declaratie zien als
Vector<Integer> i.p.v Vector<int>

Dat denk ik idd.

[whoami]

bazzs2001 schreef op 20 november 2002 @ 15:52:
[...]

werkt "int foo = v.get(0);"
niet gewoon, of moet je het na de declaratie zien als
Vector<Integer> i.p.v Vector<int>

(bazzs is toch wel geintreseert in C# ook al kan die het nog niet)

Wel, die generics zijn nog niet geimplementeerd in C#, maar een van de voordelen ervan is wel dat je niet meer zult moeten casten in die gevallen:

Nu doe je bv.

code:

ArrayList myList = new ArrayList();
myList.Add (5);
int a = (int)myList[0];

Met generics zul je die cast achterwege kunnen laten, want een template verwacht dat een bepaald datatype ipv ieder datatype dat van object afgeleid is:

code:

ArrayList myList = new ArrayList<int>;
myList.Add (5);
int a = myList[0];

(Zie ook een andere thread hier op P&W: [rml][ .NET] New language features in C#[/rml])

Edit: Te vlug gelezen en volledig anders geinterpreteerd, die vraag...

[bazzs2001]

half offtopic (dit is een java/.NET topic):
weet iemand al wanneer generics standaard in mijn koffie (java dus) komen?, ik meen ergens JDK 1.5 gelezen te hebben.

[Alarmnummer]

Yep, maar je kan wel gj van de sunsite afhalen. Dit slagroompje komt vanaf 1.5 standaard in de koffie