[Java] Object vs primitieve

[NetForce1]

Wat ik me dus afvraag is, wat is precies het verschil tussen bijv. Integer en int, waarom wordt er nooit Integer gebruikt ipv int?

[mbravenboer]

De object-varianten van primitieven zijn voor andere doeleinden. Niet-object primitieven wil je eigenlijk helemaal niet hebben in een taal, maar vanwege performance redenen zijn ze helaas noodzakelijk.

De object-varianten (Integer en dergelijke) zijn volwaardige objecten en worden daarom op de heap gealloceerd. Bovendien zijn ze ook nog immutable. Heap-allocatie is behoorlijk duur en daarom niet goed te gebruiken voor alle simpele berekeningen zoals bijvoorbeeld een loop variabele. Gewone primitieven worden gewoon op de stack gealloceerd. Dit is een stuk goedkoper. Bovendien hoef je nu niet voor elke waarde een nieuw object aan te maken.

Daarom is er dus een scheiding: primitieven voor gewone berekeningen, maar als je een primitieve echt als een object moet gebruiken kan je hem in een wrapper stoppen. Hierdoor kan je primitieven toch in een generieke verzameling stoppen. Bovendien zijn deze object-varianten noodzakelijk voor invocatie via reflectie.

Hier (en op veel meer plaatsen op het web) kan je meer info vinden:
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html

[NetForce1]

thanks voor alweer een grandioze uitzeg

[Verwijderd]

Op dinsdag 12 februari 2002 22:51 schreef mbravenboer het volgende:
De object-varianten van primitieven zijn voor andere doeleinden. Niet-object primitieven wil je eigenlijk helemaal niet hebben in een taal, maar vanwege performance redenen zijn ze helaas noodzakelijk.

Neemt niet weg dat ik me vreselijk hekel aan de object-varianten.

Ik ben een database applicatie aan het maken en de toolkit die ik ervoor gebruik geeft alles als een object terug...dus ook de data.

Nou wil ik zelf alles in een float[] hebben omdat ik de data naar een image wil kunnen converteren.

Ik ben me helemaal ziek aan het parsen

Je kan mij niet wijs maken dat daar mijn applicatie nou sneller van aan het worden is

[Tomatrix]

Op woensdag 13 februari 2002 07:48 schreef mr.beidehand het volgende:
Ik ben me helemaal ziek aan het parsen

Wat ben je aan het parsen dan?

[Verwijderd]

Op woensdag 13 februari 2002 09:03 schreef Tomatrix het volgende:

[..]

Wat ben je aan het parsen dan?

switch(dataType)
{
case Constants.DFNT_INT16:
case Constants.DFNT_UINT16:
for(int j = 0;j<imagesize;j++){
Short sh = (Short)Array.get(data,j);
imageData[j] = sh.floatValue();
}
break;
case Constants.DFNT_INT32:
case Constants.DFNT_INT64:
case Constants.DFNT_INT128:
case Constants.DFNT_UINT32:
case Constants.DFNT_UINT64:
case Constants.DFNT_UINT128:
for(int j = 0;j<imagesize;j++){
Integer in = (Integer)Array.get(data,j);
imageData[j] = (float)in.intValue();
}
break;

//Floats
case Constants.DFNT_FLOAT32:
case Constants.DFNT_FLOAT64:
case Constants.DFNT_FLOAT128:
for(int j = 0;j<imagesize;j++){
Float f = (Float)Array.get(data,j);
imageData[j] = f.floatValue();
}
break;

case Constants.DFNT_INT8:
case Constants.DFNT_UINT8:
case Constants.DFNT_UCHAR8:
case Constants.DFNT_UCHAR16:
case Constants.DFNT_CHAR8:
case Constants.DFNT_CHAR16:
for(int j = 0;j<imagesize;j++){
Byte by = (Byte)Array.get(data,j);
imageData[j] = (float)by.byteValue();
}
break;
}

[Tomatrix]

Waarom doe je niet:

code:

for (int i = 0; i < data.length; i++) {
   Number n = (Number)data [i];
   imageData [i] = n.floatValue ();
}

Ben je meteen van die switch af.

[drm]

NetForce1:
Wat ik me dus afvraag is, wat is precies het verschil tussen bijv. Integer en int, waarom wordt er nooit Integer gebruikt ipv int?

* drm moet denken aan een discussie die hier een tijdje geleden was...

ff zoeken
_{edit: gevonden}

Staan ook vast hele interessante dingen in:
[topic=368812]

[ACM]

Op dinsdag 12 februari 2002 22:51 schreef mbravenboer het volgende:
Niet-object primitieven wil je eigenlijk helemaal niet hebben in een taal, maar vanwege performance redenen zijn ze helaas noodzakelijk.

Volgens mij maakt dat de implementatie van de Java taal ansich ook extreem moeilijk als je alle primitieven zou "afschaffen".

Aangezien uiteindelijk alle Objecten uit (verzamelingen van) primitieven bestaan... (bij mijn weten dan )

[drm]

ACM:
Volgens mij maakt dat de implementatie van de Java taal ansich ook extreem moeilijk als je alle primitieven zou "afschaffen".

Aangezien uiteindelijk alle Objecten uit (verzamelingen van) primitieven bestaan... (bij mijn weten dan )

Lees dat andere topic even door, daar hebben mbravenboer en ik (al zeg ik het zelf) redelijke argumenten om een taal puur op basis van objecten te definieren

[ACM]

Op woensdag 13 februari 2002 10:06 schreef drm het volgende:
Lees dat andere topic even door, daar hebben mbravenboer en ik (al zeg ik het zelf) redelijke argumenten om een taal puur op basis van objecten te definieren

Heb je ook gezien hoe lang die thread is?

Vat jij es samen wat de belangrijkste argumenten zijn?

Maar ik had het met deze opmerking wel redelijk specifiek over java, alhoewel ik denk dat de uiteindelijke afbeelding op primitieven geen onhandige oplossing is.

[drm]

ACM:
Heb je ook gezien hoe lang die thread is?

ja

Vat jij es samen wat de belangrijkste argumenten zijn?

Yes sir!
* drm gaat even wat quotes uit dat andere topic vissen...

Maar ik had het met deze opmerking wel redelijk specifiek over java, alhoewel ik denk dat de uiteindelijke afbeelding op primitieven geen onhandige oplossing is.

da's alvast een begin

_edit:
dat samenvatten is dus een drama, er is zoveel gezegd in dat topic...

ehmm lees 't ongeveer vanaf post #11700797

[Verwijderd]

Op woensdag 13 februari 2002 09:29 schreef Tomatrix het volgende:
Waarom doe je niet:

code:

for (int i = 0; i < data.length; i++) {
   Number n = (Number)data [i];
   imageData [i] = n.floatValue ();
}

Ben je meteen van die switch af.

Joh...Thanks.....wist ik nie.....

......vandaar...weer wat geleerd :-)

[mbravenboer]

ACM: Volgens mij maakt dat de implementatie van de Java taal ansich ook extreem moeilijk als je alle primitieven zou "afschaffen".

Dat valt mee: je kunt in principe gewoon met de object varianten werken. Je moet dan alleen int literals en de rekenkundige operatoren beschouwen als sugar voor de object-varianten.

ACM: Vat jij es samen wat de belangrijkste argumenten zijn?

Als ik het me goed herrinner (heb de draad niet terug gekeken) hebben we het daar gehad over een stuke at-compile-time detectie.

De gedacht was dat je alle 'primitieven' als een object kunt gebruiken en dus gewoon in een lijst kunt stoppen etc. De compiler gaat dan echter uitzoeken of voor een primitieve het beste een 'klassieke primitieve' of een object variant gebruikt moet worden. In heel veel gevallen zal hier de primitieve gekozen kunnen worden.

De centrale gedachte is dat deze optimalisatie een detail is waar je een programmeur niet mee lastig hoeft te vallen. Uiteraard moet je dan wel een vrachtje syntaxtische suiker hebben (die er nu al is, alleen dan met een andere betekenis) omdat operaties op objecten niet bepaald handig zijn.

Merk het belangrijke verschil op met de oplossing van C#: er vindt dus geen auto-boxing plaats 'wanneer dit nodig is'. Bij onze oplossing wordt at compile time geanalyseerd of een primitieve escaped of niet en of hij daarom als value-type op de stack gebruikt kan worden.

Merk ook op dat je dit nog generieker kunt gaan aanpakken en deze analyse voor alle objecten kunt gaan doen. Je kunt objecten dan dus op de stack gaan plaatsen. Naar deze analyse is al erg veel onderzoek naar gedaan...