Het spijt me maar ik krijg steeds het gevoel dat je soms op iemand anders reageert dan op mij. Waar je eerst leek te reageren op een stelling dat er geen onderzoek naar het vergelijken van strings meer wordt gedaan (wie zei dat dan? ik niet dacht ik), heb je het nu ineens over een interpreter die ik niet genoemd heb.
Java is al eeuwenlang geen volledige interpreter meer. De meeste structuren worden nu ook gecompileerd (JIT compilatie). Dat argument slaat dus op niks.
Ik weet heus wel dat Java JIT gecompileerd is en dat is totaal irrelevant voor deze discussie. Mijn punt was, nogmaals: stel dat waarde 'a' (uit 317070's voorbeeld) een methodeaanroep is (zeg: geeft een random getal terug en kost 2 seconden om die te berekenen). Die compiler zal waarschijnlijk slechts eenmaal een instructie emitten waarbij de waarde van de methode wordt berekend en opgehaald, en die opgehaalde waarde dan steeds laten vergelijken in de switch. Voor meerdere if-jes is dit zeker niet het geval en wordt de methode steeds aangeroepen als deze nodig is voor de if. Dus een switch
kan sneller zijn, en mijn argument slaat op deze discussie.
Over je andere argumenten: sorry maar ik verkies duidelijkheid boven het terugbrengen van het aantal regels. En dat zou elke programmeur moeten doen. Verder denk ik: veel plezier met het gebruik van een hashmap voor je 3 commando's. Waarom makkelijk doen als het moeilijk kan toch? Gebruik je nu werkelijk hashmaps voor alle stringvergelijkingen? En hoe doe je dat met de enums die ik noemde? Hoe ziet een hashmap-implementatie eruit t.o.v. hetzelfde als een switch implementatie? Hoeveel regels kost het om, in de toekomst, één commando aan je hashmap toe te voegen, en hoeveel kost het om datzelfde aan een switch toe te voegen?
Bij een switch zijn alle 'keys' (mogelijke waarden) van te voren bekend. Als je hier een hashmap van maakt moet je dus een perfecte hash functie hebben om in de slechtst mogelijke situatie snel genoeg te zijn. Hoe krijg jij in Java zo'n functie ingesteld?
Een Hashmap is bijvoorbeeld ingesteld op een maximale load van 0.7. Oftewel, het kost 21% van het geheugengebruik van een switch extra door een hashmap te gebruiken (zonder overhead).
Enne... in een switch kan je de geprefereerde keus hoger in de lijst zetten. En je kan de rest afvangen met een 'default' clausule. Knappe kop die beide met een hashmap voor mekaar krijgt, nietwaar?
Trouwens, is 317070's voorbeeld niet veel duidelijker? Vooral als je je voorstelt dat 'a' mogelijk een lange expressie zou kunnen zijn.
Het spijt me maar ik krijg steeds het gevoel dat je soms op iemand anders reageert dan op mij. Waar je eerst leek te reageren op een stelling dat er geen onderzoek naar het vergelijken van strings meer wordt gedaan (wie zei dat dan? ik niet dacht ik), heb je het nu ineens over een interpreter die ik niet genoemd heb.
[quote]Java is al eeuwenlang geen volledige interpreter meer. De meeste structuren worden nu ook gecompileerd (JIT compilatie). Dat argument slaat dus op niks.[/quote]
Ik weet heus wel dat Java JIT gecompileerd is en dat is totaal irrelevant voor deze discussie. Mijn punt was, nogmaals: stel dat waarde 'a' (uit 317070's voorbeeld) een methodeaanroep is (zeg: geeft een random getal terug en kost 2 seconden om die te berekenen). Die compiler zal waarschijnlijk slechts eenmaal een instructie emitten waarbij de waarde van de methode wordt berekend en opgehaald, en die opgehaalde waarde dan steeds laten vergelijken in de switch. Voor meerdere if-jes is dit zeker niet het geval en wordt de methode steeds aangeroepen als deze nodig is voor de if. Dus een switch [i]kan[/i] sneller zijn, en mijn argument slaat op deze discussie.
Over je andere argumenten: sorry maar ik verkies duidelijkheid boven het terugbrengen van het aantal regels. En dat zou elke programmeur moeten doen. Verder denk ik: veel plezier met het gebruik van een hashmap voor je 3 commando's. Waarom makkelijk doen als het moeilijk kan toch? Gebruik je nu werkelijk hashmaps voor alle stringvergelijkingen? En hoe doe je dat met de enums die ik noemde? Hoe ziet een hashmap-implementatie eruit t.o.v. hetzelfde als een switch implementatie? Hoeveel regels kost het om, in de toekomst, één commando aan je hashmap toe te voegen, en hoeveel kost het om datzelfde aan een switch toe te voegen?
Bij een switch zijn alle 'keys' (mogelijke waarden) van te voren bekend. Als je hier een hashmap van maakt moet je dus een perfecte hash functie hebben om in de slechtst mogelijke situatie snel genoeg te zijn. Hoe krijg jij in Java zo'n functie ingesteld?
Een Hashmap is bijvoorbeeld ingesteld op een maximale load van 0.7. Oftewel, het kost 21% van het geheugengebruik van een switch extra door een hashmap te gebruiken (zonder overhead).
Enne... in een switch kan je de geprefereerde keus hoger in de lijst zetten. En je kan de rest afvangen met een 'default' clausule. Knappe kop die beide met een hashmap voor mekaar krijgt, nietwaar?
Trouwens, is 317070's voorbeeld niet veel duidelijker? Vooral als je je voorstelt dat 'a' mogelijk een lange expressie zou kunnen zijn.
