[Java] Converteren van object naar double

[Verwijderd]

Hallo,

Mijn vorige draadje kreeg een slotje omdat ik te weinig uitlegde wat het probleem was en wat ik geprobeerd had.


Nu mijn uitleg:
Ik probeer een double in een vector te plaatsen. Aangezien er allen objecten in een vector kunnen zal ik de double moeten converteren.

Het plaatsen in de vector lukt:

code:

String invoer = vector.addElement(invoer);

Maar nu wil ik uit de vector vanaf een bepalde positie een object lezen, en deze converteren naar double. Dit heb ik geprobeerd:

code:

double getal = Double.ParseDouble(vector.elementAt(i));

Maar dit blijkt niet te lukken, het converteren naar double lukt totaal niet. Op zich logisch want hij wil tussen de haakjes een String hebben. Alleen ik heb geen idee hoe ik kan converteren.

Hopelijk dit dit topic wel goed, sorry ben een newbie op dit forum.....

[Eskimootje]

Een Double is volgens mijn geen double en moet je hem daarom verder door casten. Staat wel ergens op een site. (oh jaah het is converteren met een o )

[Verwijderd]

Het probleem is juist dat ik niet weet hoe ik verder kan casten

[Eskimootje]

Dan zou je is ff een manual kunnen lezen of www.google.com gebruiken. we gaan het niet voorkauwen dan leer je er namelijk nix van.

[Verwijderd]

sorry ik heb gezocht, maar ik heb nog niks bruikbaars gevonden. Ook de search hier op got leverde niets op.

[ACM]

Lang leve het casten...

Je weet hoe parseDouble werkt, je weet wat vectors zijn, maar je krijgt het niet voor elkaar de input dusdanig aan te reiken (dmv een cast bijv) dat je de double ook kan parsen

Btw, ik zou er geen Strings inzetten maar Doubles, zo verlies je minder informatie en is je opslag sneller, naast dat je geen extra conversies hoeft te doen.

[Verwijderd]

Ik heb het verandert, hij zet er nu doubles in. Alleen ontvang ik de foutmelding: Cannot cast java.lang.Object to object.

Mijn probleem is dus dat ik niet weet hoe te casten van double naar object en omgekeerd.

PS bedankt voor de reacties tot op dit moment!

[.oisyn]

Cannot cast java.lang.Object to object

klopt die error wel? (en geef de code eens bij die error)

[Verwijderd]

oops sorry:

error: cannot cast java.lang.Object to double

[.oisyn]

(en geef de code eens bij die error)

[ACM]

doubles, Doubles, object, Objects, whats the difference he...

[Verwijderd]

er staat letterlijk:

code:

Error: (114) cannot cast to java.lang.Object to double.

[Verwijderd]

Ps weten jullie misschien een goed boek voor java? Ik gebruik momenteel "Java stap voor stap" van Bell en Parr

[.oisyn]

*zucht*

post nou eens de code die die error genereert
of is dat deze code:

Java:

double getal = Double.ParseDouble(vector.elementAt(i));

Dat is logisch, want Vector.elementAt () geeft een Object terug, dus die moet je eerst naar een Double String casten

[Verwijderd]

code:

  void button_voegToe_actionPerformed(ActionEvent e) {
    String getInvoer = textField_invoer.getText();
    double invoer = Double.parseDouble(getInvoer);
    Object test = (double)vector.elementAt(0);
    vector.addElement(invoer);
  }

Error wordt gegenereerd door:

code:

Object test = (double)vector.elementAt(0);

Hier is de error: (98) cannot cast to java.lang.Object to double.

Logische error, maar dit was een van de pogingen......

[Tuinhark]

Voor de goede orde, je snapt toch het verschil tussen een double en een Double?

En nee, dit is geen strikvraag met als antwoord: een typfout.

[Verwijderd]

Sorry Tuinhark. Java is mijn eerste programmeertaal die ik onder de knie probeer te krijgen. Het verschil zou ik niet weten.

Verder heb ik al wel enige voortgang in mijn projectje:

code:

String getInvoer = textField_invoer.getText();
    double invoer = Double.parseDouble(getInvoer);
    vector.add(new Double(invoer));

vector wordt nu met doubles gevuld .

Blijf ik zitten met het punt het uitlezen van de objecten en converteren naar double...

[Tuinhark]

Dat is het em dus. Zodat je dat verschil doorhebt, kun je verder. Maw, als je het verschil tussen double en Double opzoekt, kom je al een heel eind. (Hint voor de index van je boek: objecten en primitieve typen)

BTW, goede keus met Java als eerste programmeertaal.

[.oisyn]

Verwijderd schreef op 20 september 2002 @ 02:11:

Java:

  void button_voegToe_actionPerformed(ActionEvent e) {
    String getInvoer = textField_invoer.getText();
    double invoer = Double.parseDouble(getInvoer);
    Object test = (double)vector.elementAt(0);
    vector.addElement(invoer);
  }

ok, je vraagt eerst de invoer op, dan converteer je die naar double.

Vervolgens haal je element 0 uit de Vector, die je cast naar double, en vervolgens weer wilt opslaan als een Object Afgezien van het feit dat hier niets naar klopt, waarom wil je dat doen?

En vervolgens probeer je een double toe te voegen (terwijl je alleen maar objecten kunt toevoegen)

Goed, eerst even een korte uitleg:

double is een zogenaamde primitive, en dus geen class. Je kunt ze dus ook niet casten naar een Object (wat een class is), noch kun je een Object casten naar een primitive
Double is een class. Standaard is elke class in java een subclass van Object. Downcasten gaat automatisch (Dus van Double naar Object), aangezien elke Double een Object is, maar upcasten moet je expliciet doen door het type wat je wilt tussen haakjes te zetten (immers, niet elke Object hoeft een Double te zijn)

De klassen Double, Integer en al dat soort klassen zijn in het leven geroepen om primitives te encapsuleren: je kunt er dus een primitive in stoppen. Zonder deze klassen zou het niet mogelijk zijn om primitives in een Vector te stoppen (tenzij je je eigen klasse maakt natuurlijk )

Dus de werkwijze is als volgt:

double in een Vector stoppen;
- creeer een Double met daarin je waarde
- stop deze in de Vector

double uit een Vector halen:
- haal het Object uit de Vector
- cast deze naar Double
- lees de waarde uit

[TaXaN]

double, int, ... zijn primitieve types. In een Vector kan je enkel objecten steken. Primitieve types zijn geen objecten. Je moet dus een soort conversie doen van primitief type naar object.
Hint: wrapper classes. Je zit al dichtbij.

[Verwijderd]

code:

    Double test = (Double)vector.get(0);
    textField_uitvoer.setText("" +test);

Dit heb ik gebruikt voor uitlezen, en het werkt perfect

Bedankt voor de uitleg .oisyn !!!

Sorry dat ik nog zo newbie achtig doe, maar java is totaal nieuw en tevens de eerste programmeertaal voor mij.

En ja die code is beetje brak...Komt doordat ik nog aan het klooien was met casten.

Verder als ik het goed begrijp kan ik van Double (class) niet casten naar double (primitief). Toch wil ik de waarde van Double in een double hebben. MOet ik dit dan eerst weergeven in een tekstvak en daarna opvragen met getText(). Met als gevolg dat ik die string moet casten naar double?

Of kan het ook anders?

[Alarmnummer]

double x = test.doubleValue();

en ik adviseer je even om goed door de documentatie te kijken:
http://java.sun.com/j2se/...api/java/lang/Double.html

moet je ff in je favorites zetten
-api doc
http://java.sun.com/j2se/1.4.1/docs/api/index.html
-sdk doc
http://java.sun.com/j2se/1.4.1/docs/
-voor searchen:
http://search.java.sun.com

En verder adviseer ik je om gui een beetje links te laten liggen. Omdat dit vrij gecompliceerd is en je zult eerst een solide basis moeten krijgen. En dit kan ook zeker geen kwaad.

[Verwijderd]

Harstikke bedankt alarmnummer!!! Die tips die je geeft zijn errug bruikbaar!!!!

[Soultaker]

Ik zal dit topic maar onthouden voor als ik argumenten nodig heb voor de stelling "primitieve types in een object-georienteerde taal zijn slecht". Natuurlijk had de topicstarter de Java tutorial wat beter kunnen lezen, maar uit het feit dat 'ie wel weet hoe objecten en methoden werken (en dat een String bijvoorbeeld eerst geparsed moet worden voordat er een double uit kan komen) maar niet overweg kan met primitieve en wrapper types, blijkt wel dat deze situatie onnodig ingewikkeld is.

Als Java aspireert een beginnerstaal te zijn, dan zijn dit soort vreemde constructies absoluut uit den boze. Mij is trouwens nog steeds niet duidelijk waarom die primitieve typen ueberhaupt in de taal zitten. Ze voegen absoluut niets toe.

[ACM]

Mja, daar krijg je weer zo'n ellenlange discussie mee die oa duidelijkheid etc op verschillende manieren kan uitleggen.

Java:

Integer LIMIT = new Integer(); // limit = 0
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment(); // Limit = 9
for(Integer i = new Integer(); i.smallerThan(LIMIT); i.increment() )
{
   etc
}

Java:

for(int i = 0; i < 9 i++)
{
}

Welke is duidelijker en tot hoever moet je het weglaten van primitieven doortrekken?

[Woy]

ACM schreef op 20 september 2002 @ 11:52:
Mja, daar krijg je weer zo'n ellenlange discussie mee die oa duidelijkheid etc op verschillende manieren kan uitleggen.

Java:

Integer LIMIT = new Integer(); // limit = 0
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment();
LIMIT.increment(); // Limit = 9
for(Integer i = new Integer(); i.smallerThan(LIMIT); i.increment() )
{
   etc
}

Java:

for(int i = 0; i < 9 i++)
{
}

Welke is duidelijker en tot hoever moet je het weglaten van primitieven doortrekken?

Dat is dan weer te voorkomen door opperator overloading

[ACM]

rwb schreef op 20 september 2002 @ 11:54:
Dat is dan weer te voorkomen door opperator overloading

De smallerThan wel ja...

Maar de rest?
Hoe geef je een waarde aan een object dat een primitieve representeert zonder de primitieve?

En trouwens, operator overloading...

Soultaker schreef op 20 september 2002 @ 11:38:
Als Java aspireert een beginnerstaal te zijn, dan zijn dit soort vreemde constructies absoluut uit den boze. Mij is trouwens nog steeds niet duidelijk waarom die primitieve typen ueberhaupt in de taal zitten. Ze voegen absoluut niets toe.

[Alarmnummer]

Soultaker schreef op 20 september 2002 @ 11:38:
Als Java aspireert een beginnerstaal te zijn, dan zijn dit soort vreemde constructies absoluut uit den boze. Mij is trouwens nog steeds niet duidelijk waarom die primitieve typen ueberhaupt in de taal zitten. Ze voegen absoluut niets toe.

Ik ben het met je eens dat het onnodig gecompliceerd is. Maar het is denk ik gedaan voor de performance en om de overgang van andere talen niet al te groot te laten lijken (en dan bedoel ik met name delphi,c++ etc). Vooral in het begin zou het 'correct' zijn van java een vroeg tijdig falen hebben betekend omdat mensen iets willen dat praktisch, herkenbaar en snel is ipv iets dat krachtig is.

Daarom ben ik bv ook wel blij met autoboxing, maar eigelijk zou ik helemaal geen primitieve types meer willen zien. Zoals martin al zei: laat de runtime env/compiler het maar uitzoeken.

[TheOneLLama]

rwb schreef op 20 september 2002 @ 11:54:
[...]

Dat is dan weer te voorkomen door opperator overloading

Ik denk dat als je moet kiezen wat voor een beginner ingewikkelder is, primitives of operator overloading.. dan weet ik het wel.
Ze hadden natuurlijk voor autoboxing kunnen kiezen zonder operator overloading en verlies van primitives.

[Alarmnummer]

TheOneLLama schreef op 20 september 2002 @ 13:22:
Ik denk dat als je moet kiezen wat voor een beginner ingewikkelder is, primitives of operator overloading.. dan weet ik het wel.

Op dit moment is er bij primitives ook sprake van operator overloading.

Ze hadden natuurlijk voor autoboxing kunnen kiezen zonder operator overloading en verlies van primitives.

Als je autoboxing gaat toevoegen dan zul je nog steeds operator overloading willen gebruiken om een beetje een vriendelijke syntax te kunnen gebruiken. Operator overloading heeft niets te maken met wel of niet 'object' zijn. Het wordt gebruikt om voor verschillende types eenzelfde operator naam te gebruiken maar waarvan de implementatie per type verschilt.

[Alarmnummer]

rwb schreef op 20 september 2002 @ 11:54:
Dat is dan weer te voorkomen door opperator overloading

Precies. Syntax is een 'visualisatie' van de IR, maar er zijn zoveel verschillende visualisaties van die IR mogelijk. En daarom ben je niet gebonden aan een 'oo' syntax omdat dit maar een van de vele mogelijke visualisaties is.

[TheOneLLama]

Alarmnummer schreef op 20 september 2002 @ 13:44:
[...]

Op dit moment is er bij primitives ook sprake van operator overloading.


[...]

Als je autoboxing gaat toevoegen dan zul je nog steeds operator overloading willen gebruiken om een beetje een vriendelijke syntax te kunnen gebruiken. Operator overloading heeft niets te maken met wel of niet 'object' zijn. Het wordt gebruikt om voor verschillende types eenzelfde operator naam te gebruiken maar waarvan de implementatie per type verschilt.

Hm het komt wel heel verkeerd over wat ik schreef... niet in de laatste plaats omdat ik m'n termen door elkaar aan het halen ben Laat maar zitten dus

[mbravenboer]

Hier een stukje over mijn anti-primitieve en anti-auto-boxing argumenten"

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...

Ik verwacht eigenlijk in dat de compiler in de toekomst een stukje analyse zal gaan doen en het onderscheid tussen primitieven en objecten weg zal vallen. Omdat de wrappers 1 op 1 mappen op primitieve typen maakt het namelijk niet uit welke van de twee je gebruikt. Je kan hierdoor de primitieven gewoon weggooien en de compacte syntax in feite laten staan voor echte objecten. Uiteraard gaat dit hele waardeloze performance opleveren omdat je in dat geval overal met objecten werkt die voortdurend garbage zullen veroorzaken. Een slimme compiler zal echter kunnen nagaan of de objecten misschien vervangen kunnen worden door de oude primitieven.

Merk wel op dat dit iets heel anders is dan auto-boxing in C#. In C# wordt een primitieve naar behoefte omgezet in een object: zodra een primitieve als een object wordt gebruikt, wordt hij ingepakt in een box. Zodra hij weer als een object wordt gebruikt, wordt hij weer uitgepakt.

Mijn voorstel is anders: het gebruike van echte primitieven is hier een optimalisatie detail, wat volledig afgehandeld wordt door de compiler. Alles is gewoon altijd een object (merk op dat dat iets essentieel anders is dan dat iets altijd omgezet kan worden in een object) en de compiler analyseert of dit misschien efficient met behulp van echte primitieven kan worden gecompileerd.

Paar topics:
[rml][ Java] Object vs primitieve[/rml]
[rml][ JAVA] operator overloading gefaked?[/rml]
[rml][ Java] Output parameters[/rml]
Programmeer ergenissen top 10 :)

[Soultaker]

Ten eerste denk ik niet dat het gebruiken van overloaded operators ingewikkelder is dan het gebruiken van operators op primitieve typen. Voor de 'domme' gebruiker is het namelijk precies hetzelfde.

Ten tweede kent Java al een soort van operator overloading, in die zin dat + operator op String objecten overloaded is (normaliter werkt + uitsluitend op primitives).

Ten derde is er geen enkele reden waarom je (bijvoorbeeld) Integer objecten niet met een waarde mag instantieren. '9' zou prima een object kunnen zijn, net zoals ' "test" ' nu al een String object is. Het verhaal van ACM gaat dan niet op.

Het lijkt me dus, dat als je primitieven afschaft, er voor de gewone gebruiker niets veranderd. Alle code kan in principe hetzelfde blijven. Het enige verschil is dat je zonder gezeur primitives in container types en dergelijke kunt stoppen.

Het argument dat objecten 'duur' zijn om te maken gaat niet helemaal op, aangezien er geen enkele reden is (in een hypothetische Java variant dus) waarom de compiler niet zo kunnen beslissen om objecten unboxed op te slaan.

[Alarmnummer]

Java heeft sowieso al operator overloading bij de primitieve types, bv + bij int,long,float,double.

Daarnaast zou ik het ook wel erg fijn vinden als ze net zo`n strakke type hierarchie gingen maken als in Haskell bv.

Als je class bv geen Eq(uals) interface implementeert, dan mag je er ook geen equals op uitvoeren. En daarnaast ben ik ook voor veel operator overloading om die syntax wat leesbaarder te krijgen.

[Soultaker]

Alarmnummer schreef op 20 september 2002 @ 18:41:
Als je class bv geen Eq(uals) interface implementeert, dan mag je er ook geen equals op uitvoeren. En daarnaast ben ik ook voor veel operator overloading om die syntax wat leesbaarder te krijgen.

Het vervelende aan 'equals' in Java is natuurlijk dat er geen onderscheid is tussen objecten en references (daar heb ik het al eerder over gehad trouwens). Het is dus niet mogelijk om (met de == operator) onderscheid te maken dus het vergelijken van de references (of die naar hetzelfde fysieke object verwijzen) en het vergelijken van de objecten (of die misschien wel verschillend zijn, maar eenzelfde identiteit hebben).

Daarom is het logisch dat er een equals methode geintroduceerd is. Het is alleen heel erg jammer dat de default implementatie (in Object) die al implementeert en alle afgeleide objecten (ALLE objecten dus) al meteen een equals operator kado krijgen, of die nu zinnig is of niet. Ik had me eerder kunnen voorstellen dat je dan een statische methode definieert die twee argumenten van die klasse krijgt, zodat een operatie als "Derived.equals(a,b)" alleen werkt als a en b inderdaad van type Derived (of een subklasse) zijn en als de equals methode ook daadwerkelijk geimplementeert i s.

Maar deze discussie gaat helemaal de verkeerde kant op, geloof ik.

[Alarmnummer]

Nee hoor, hij gaat de interessante kant op

Je zou voor dat probleem wel nieuw symbool voor kunnen bedenken. Ik vind dat niet zo`n groot probleem (vooral als je er vanuit gaat dat je java dus al helemaal op zijn kop hebt gezet)

[Alarmnummer]

Het is inderdaad logisch dat er voor iedere class een referentie equals is geimplementeerd, maar ik ben dus niet voor die standaard inhoudelijke equals van object. Ten 1e omdat je dus bij ieder object een equals hebt terwijl je daar niet altijd nodig is, en ten tweede omdat je alles met alles kan vergelijken en dat niet compile time goed kan krijgen.

[mbravenboer]

Soultaker: Daarom is het logisch dat er een equals methode geintroduceerd is. Het is alleen heel erg jammer dat de default implementatie (in Object) die al implementeert en alle afgeleide objecten (ALLE objecten dus) al meteen een equals operator kado krijgen, of die nu zinnig is of niet.

Heel sterk punt. Compleet mee eens (maar dat had je misschien al verwacht ). Hetzelfde geldt overigens voor hashCode en toString(). Het hele concept toString vind ik overigens matig.