Van de voorbeelden vind ik het belangrijkst, het feit dat je nu String in switches kunt gebruiken.The JDK currently has a release date of September 2010.
Van de voorbeelden vind ik het belangrijkst, het feit dat je nu String in switches kunt gebruiken.
Dat is compleet onzin. Misschien heb jij de switch niet nodig gehad, maar als je actief probeert om geen switch te gebruiken (vervangen door if's of een functiepointerarray) dan ben je slecht bezig. De switch is erg handig om structuur aan te brengen in code die verschillend reageert over verschillende waarde van dezelfde variabele. Dat die 'verschillende waarde' nu ook een string kan zijn is daarom juist een verbetering.Imo totaal nutteloos omdat als je veel strings moet gaan vergelijken er altijd wel snellere, betere en makkelijkere methoden bestaan. Sowieso is een switch iets dat je nog zelden zou moeten gebruiken (eigenlijk zelf de laatste jaren totaal niet meer gebruikt).
Dan heb je toch maar een beperkte kennis van zaken, want laat het vergelijken van strings nu net een tak in de informatica zijn waar veel onderzoek in gebeurt is geweest en nog steeds is.De enige mogelijk snellere string vergelijkingsmethode die ik kan bedenken is met een tree en dat is absoluut niet makkelijker.
Laat ik het zo zeggen: ik weet hier voldoende over om er wat zinnigs over te kunnen zeggen. En een hashmap geïmplementeerd met een boom zeg je? Dus zoals ik zei: de enige snellere manier die ik ken is d.m.v. een tree. Maar dat is niet zo makkelijk als een switch. En ja, een switch kan worden geïmplementeerd als een if/then/else-constructie en dan is het dus even snel, zoals ik ook zei. Alleen is een switch leesbaarder. En waarschijnlijk is een switch sneller omdat de compiler slechts eenmaal de waarde ophaalt en daarna steeds vergelijkt, terwijl vaak meerdere if-jes meerdere malen de waarde ophalen (afhankelijk van hoe je compiler optimaliseert).Cycloon schreef:Dan heb je toch maar een beperkte kennis van zaken, want laat het vergelijken van strings nu net een tak in de informatica zijn waar veel onderzoek in gebeurt is geweest en nog steeds is.
...
Vanaf je meerdere strings hebt kan je beter een hashmap gaan gebruiken (die geïmplementeerd worden dmv rood/zwart bomen en altijd performanter zullen zijn dan je switch). Het gebruik van een hashmap is simpel en werkt sneller dan een switch.
Bij Java heb ik geleerd NOOIT uit te gaan van hun implementatie. Ik zou bij deze dus verwonderd zijn moesten ze het zo doen.Hoe denk je dat een switch statement praktisch wordt uitgevoerd? Ja, door een if/else constructie.
Vooreerst is snelheid tegenwoordig lang niet altijd zo belangrijk meer (en al zeker niet als je toch Java gebruikt). Hoe je die hashmap daarvoor wilt gebruiken zie ik ook niet direct, en dat op zich wil al zeggen dat het een goede verbetering is. Meestal worden die dingen nu toch al als if/else lussen ingebouwd, dus kan het enkel een verbetering zijn.Cycloon schreef:Voor 2-3 strings kan het nog wel voordelig zijn (maar dan typ je evensnel een if/else structuur dan een switch). Vanaf je meerdere strings hebt kan je beter een hashmap gaan gebruiken (die geïmplementeerd worden dmv rood/zwart bomen en altijd performanter zullen zijn dan je switch). Het gebruik van een hashmap is simpel en werkt sneller dan een switch.
Op het moment dat je ook veel strings moet gaan vergelijken die je op voorhand kent en je zo'n switch constructie wil gaan gebruiken dan zit er vaak ook wat fout aan je implementatie en zal je code nauwelijks flexibel te noemen zijn.
Java is al eeuwenlang geen volledige interpreter meer. De meeste structuren worden nu ook gecompileerd (JIT compilatie). Dat argument slaat dus op niks.En waarschijnlijk is een switch sneller omdat de compiler slechts eenmaal de waarde ophaalt en daarna steeds vergelijkt, terwijl vaak meerdere if-jes meerdere malen de waarde ophalen (afhankelijk van hoe je compiler optimaliseert).
In welke zin zou een switch duidelijker zijn dan een if/else structuur? Zelf qua aantal regels en opmaak heeft een switch nauwelijks/geen voordeel.Vooral als de code per waarde sterk verschilt loont een switch. Iemand die een switch liever vervangt door een groot aantal if-then-else clausules heeft beperkte kennis van programmeren.
Een programma die moet reageren op bepaalde commando's kan je ook weer perfect uitwerken met extra objecten die elk voor een commando staan, of wil je alle code samenproppen in je switch constructie? En het ontwerp is simpel, je maakt een interface voor je commando en je gooit al je commando objecten in een hashmap. Je programma is makkelijk uitbreidbaar en zal bij een groot aantal commando's nog steeds vlot lopen. Ok jij hebt het over een beperkte verzameling commando's, als je maar 2-3 commando's hebt lijkt het mss overkill om zoiets te gaan doen, maar als je later wil gaan uitbreiden zal je blij zijn dat er reeds een goede structuur aanwezig was.Een programma dat reageert op een beperkte verzameling commando's gebruikt een switch (met strings).
Code: Selecteer alles
String a = "abcdefg";
if(a.equals("a")){
het_is_a();
}else if(a.equals("b")){
het_is_b();
}else if(a.equals("c")){
het_is_c();
}else{
het_is_nog_iets_anders();
}Code: Selecteer alles
String a = "abcdefg";
switch(a){
case "a":
het_is_a();
break;
case "b":
het_is_b();
break;
case "c":
het_is_c();
break;
default:
het_is_nog_iets_anders();
}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.Java is al eeuwenlang geen volledige interpreter meer. De meeste structuren worden nu ook gecompileerd (JIT compilatie). Dat argument slaat dus op niks.
Hash functies zijn geamortiseerd altijd sneller dan een sequentiële doorloop van een switch constructie, zelf indien de sleutels vooraf niet bekend zijn kan je wiskundig bewijzen dat een familie van hashfuncties er voor zorgt dat de gemiddelde performantie beter zal zijn dan O(n).virtlink schreef: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?
Kan je dit, eventueel met wat voorbeelden, beter uitleggen? Heb je het nu over structuur, of ook over optimalisatie en dergelijk?Ik blijf bij mijn standpunt dat van zodra je meer dan 3 if testen nodig hebt (of 3 staten in je switchen) de geschreven code een andere structuur vraagt. Door de verdere support van switches heb ik nogal het gevoel dat slecht gestructuurde code wordt aangemoedigd.
Geamortiseerd, wat is dat?Hash functies zijn geamortiseerd...
Om even een vrij simpel voorbeeld te nemen:Geamortiseerd, wat is dat?
