---

Jeg har afprøvet denne funktion, men den virker ikke.
Selvom input er et 'F' får jeg en exception? Hvorfor?



protected void setType(char type) throws Exception {
System.out.println("" + type);
switch (type) {
case 0 : this.type = 'F';
case ' ': this.type = 'F';
case 'F': this.type = 'F';
case 'f': this.type = 'F';
case 'D': this.type = 'D';
case 'd': this.type = 'D';
case 'K': this.type = 'K';
case 'k': this.type = 'K';
default : throw new Exception("Forkert type-angivelse,
F: Finans - D: Debitor - K: Kreditor");
}
}


Mvh / Preben Holm

---

Preben Holm wrote:
> Jeg har afprøvet denne funktion, men den virker ikke.
> Selvom input er et 'F' får jeg en exception? Hvorfor?
>
>
>
> protected void setType(char type) throws Exception {
> System.out.println("" + type);
> switch (type) {
> case 0 : this.type = 'F';
> case ' ': this.type = 'F';
> case 'F': this.type = 'F';
> case 'f': this.type = 'F';
> case 'D': this.type = 'D';
> case 'd': this.type = 'D';
> case 'K': this.type = 'K';
> case 'k': this.type = 'K';
> default : throw new Exception("Forkert type-angivelse, F:
> Finans - D: Debitor - K: Kreditor");
> }
> }

Du har ikke indsat nogle break statements.

Se evt. http://www.cafeaulait.org/course/week2/40.html

Rolf

---

Hej Preben,

Man smider ikke rundt med exceptions, med mindre der virkelig er opstået
noget helt exceptionelt !!

Overvej at omskrive din metode...

/Bart


"Preben Holm" <64bitNonoSPAMno@mailme.dk> wrote in message
news:412c8091$0$229$edfadb0f@dread12.news.tele.dk...
> Jeg har afprøvet denne funktion, men den virker ikke.
> Selvom input er et 'F' får jeg en exception? Hvorfor?
>
>
>
> protected void setType(char type) throws Exception {
> System.out.println("" + type);
> switch (type) {
> case 0 : this.type = 'F';
> case ' ': this.type = 'F';
> case 'F': this.type = 'F';
> case 'f': this.type = 'F';
> case 'D': this.type = 'D';
> case 'd': this.type = 'D';
> case 'K': this.type = 'K';
> case 'k': this.type = 'K';
> default : throw new Exception("Forkert type-angivelse,
> F: Finans - D: Debitor - K: Kreditor");
> }
> }
>
>
> Mvh / Preben Holm

---

Bart Simpson wrote:
> Hej Preben,
>
> Man smider ikke rundt med exceptions, med mindre der virkelig er opstået
> noget helt exceptionelt !!

I det tilfælde kan en IlegalArgumentException måske være på sin plads.
Det er jo en unchecked exception.

mvh
henrik

---

>> Man smider ikke rundt med exceptions, med mindre der virkelig er opstået
>> noget helt exceptionelt !!

Nej, men det her "KAN IKKE" eller nærmere MÅ ALDRIG forekomme. Hvis der
forekommer andet skal der stoppes og brugeren skal foretage sig noget andet.
Du ville måske mene at en betingelse ville være på sin plads, men
eftersom der skal komme fejlbesked til brugeren og brugeren bliver nødt
til at taste noget andet, så mener jeg en Exception er på sin plads.

Btw. java standard class library smider rimelige meget rundt på Exceptions.

Derudover, hvis du udfører en funktion der hedder f.eks. setBilag() -
forventer du så ikke en Exception hvis der opstår en undtagelse og det
indtastede ikke kan bruges som bilag?


> I det tilfælde kan en IlegalArgumentException måske være på sin plads.
> Det er jo en unchecked exception.

Hmm... tja. det kunne måske være, men synes måske det er lettere at have
en simpel Exception, da fejlhåndteringen skal være den samme for en hel
række at exceptions. Dette er også begrundelsen for at jeg har taget og
lavet et catch på f.eks. ParseNumberException (mener jeg det er) og
istedet lavet en throw new Exception("Ikke et tal!").


Mvh / Preben Holm

---

> Hmm... tja. det kunne måske være, men synes måske det er lettere at have
> en simpel Exception, da fejlhåndteringen skal være den samme for en hel
> række at exceptions. Dette er også begrundelsen for at jeg har taget og
> lavet et catch på f.eks. ParseNumberException (mener jeg det er) og
> istedet lavet en throw new Exception("Ikke et tal!").

Ja det ved jeg snart ikke hvad jeg skal sige til. Men jeg tror du har glemt
polymorfisme...

ParseNumberException kan du altså fange med
catch(Exception ex) da ParseNumberException har Exception som base klasse.

Eller har jeg fuldstændig misforstået det du siger.

Anders

---

Flare wrote:
>>Hmm... tja. det kunne måske være, men synes måske det er lettere at have
>>en simpel Exception, da fejlhåndteringen skal være den samme for en hel
>>række at exceptions. Dette er også begrundelsen for at jeg har taget og
>>lavet et catch på f.eks. ParseNumberException (mener jeg det er) og
>>istedet lavet en throw new Exception("Ikke et tal!").
>
>
> Ja det ved jeg snart ikke hvad jeg skal sige til. Men jeg tror du har glemt
> polymorfisme...

Korrekt, har ikke software design mere - var til eksamen her før
sommerferien, og jeg har faktisk allerede glemt det. Men når jeg nu
tænker over det, så er det vist noget med hvordan man udvikler "plugable
software components"... og det har mig bekendt noget med interfaces at
gøre og ikke decideret nedarvning, og mønsteret er da nærmere brugt til
"Adapter"-funktionalitet. Netop at konvertere fra et "interface" til et
fast afgrænset software-interface til resten af programmet, så man kan
udskifte teknologi uden at det har betydning for resten af programmet.

Dette er nok nærmere årsagen til at jeg vil have en Exception som jeg
skal gribe.

> ParseNumberException kan du altså fange med
> catch(Exception ex) da ParseNumberException har Exception som base klasse.
>
> Eller har jeg fuldstændig misforstået det du siger.

Ja, eller dvs. jeg skriver et dansk program til danske brugere (eller
mest mig selv, men anyway). Jeg vil have mit program til at vise min
Exceptions besked (getMessage()) i en dialog eller linie et sted i
brugerfladen. Derfor vil jeg have danske fejlmeddelelser. Det er måske
korrekt at jeg så måske kunne anvende

} catch (ParseNumberException e) {
throw new ParseNumberException("Ikke et tal!");
}


men jeg får ikke noget foræret udover at skulle skrive lidt mere og
kaste flere forskellige exceptions istedet for kun en!

Jeg ved ikke om du kan følge mig her!

Men jeg har en lagdeling der hedder:
- UI
- Kernel
- Persistence

så når jeg får en fejl (Exception) fra kernel-laget og ikke aner om jeg
arbejder med et dato-felt eller et bilags-felt (pga nedarvning fra
DataFelt) - så vil jeg gerne have fejlmeddelelsen ud på skærmen. Og
derfor vil jeg være fri for at gribe både en ParseNumberException og
melde fejl for at det ikke er et tal, men en tekst. Derudover gribe for
hvis det ikke er et floating point tal eller f.eks. en dato der er
indtastet. På den måde sikrer jeg mig at jeg blot kan skrive f.eks.

} catch (Exception e) {
fejlBox.setText(e.getMessage());
}

eller noget i den stil. Alternativet ville være:

} catch (ParseNumberException) {
fejlBox.setText("Ikke et tal");
} catch (DateException) {
fejlBox.setText("Ikke en dato"); //Men jeg ved ikke om det er
måned, dag eller årstal der er "out-of-range" eller om formatet er
forkert. Dette kræver fire exceptions istedet for en.
} catch (AnotherException) {
}


giver det mening?



Mvh / Preben Holm

---

"Preben Holm" <64bitNOnoSPAMno@mailme.dk> wrote in message
news:4130c8e6$0$203$14726298@news.sunsite.dk...
> så når jeg får en fejl (Exception) fra kernel-laget og ikke aner om jeg
> arbejder med et dato-felt eller et bilags-felt (pga nedarvning fra
> DataFelt) - så vil jeg gerne have fejlmeddelelsen ud på skærmen. Og derfor
> vil jeg være fri for at gribe både en ParseNumberException og melde fejl
> for at det ikke er et tal, men en tekst. Derudover gribe for hvis det ikke
> er et floating point tal eller f.eks. en dato der er indtastet. På den
> måde sikrer jeg mig at jeg blot kan skrive f.eks.
>
> } catch (Exception e) {
> fejlBox.setText(e.getMessage());
> }
>
> eller noget i den stil. Alternativet ville være:
>
> } catch (ParseNumberException) {
> fejlBox.setText("Ikke et tal");
> } catch (DateException) {
> fejlBox.setText("Ikke en dato"); //Men jeg ved ikke om det er måned,
> dag eller årstal der er "out-of-range" eller om formatet er forkert. Dette
> kræver fire exceptions istedet for en.
> } catch (AnotherException) {
> }
>
>
> giver det mening?

Nej, ikke det mindste. Da alle exceptions nedarver fra Exception kan du
altid bare skrive catch (Exception e), hvis du ikke gider eller ikke har
brug for at håndtere exceptions forskelligt. Man bør uden tvivl benytte de
korrekte exceptions klasser, og ikke bare kaste Exception.

Christian

---

switch virker kun med int.
Værdien efter case skal være et tal:
Prøv at skrive ascii værdien direkte.
/janosh

---

Prøv:

protected void setType(char type) throws IllegalArgumentException {
System.out.println("" + type);
switch ((int)type) {
case 0 : this.type = 'F';
case ' ': this.type = 'F';
case 'F': this.type = 'F';
case 'f': this.type = 'F';
case 'D': this.type = 'D';
case 'd': this.type = 'D';
case 'K': this.type = 'K';
case 'k': this.type = 'K';
default : throw new IllegalArgumentException("Forkert
type-angivelse, F: Finans - D: Debitor - K: Kreditor");
}
}

Preben Holm wrote:
> Jeg har afprøvet denne funktion, men den virker ikke.
> Selvom input er et 'F' får jeg en exception? Hvorfor?
>
>
>
> protected void setType(char type) throws Exception {
> System.out.println("" + type);
> switch (type) {
> case 0 : this.type = 'F';
> case ' ': this.type = 'F';
> case 'F': this.type = 'F';
> case 'f': this.type = 'F';
> case 'D': this.type = 'D';
> case 'd': this.type = 'D';
> case 'K': this.type = 'K';
> case 'k': this.type = 'K';
> default : throw new Exception("Forkert type-angivelse, F:
> Finans - D: Debitor - K: Kreditor");
> }
> }
>
>
> Mvh / Preben Holm

---

The_MaXx <no-spam@spam-me.dk> writes:

> Prøv:
>
> protected void setType(char type) throws IllegalArgumentException {
> System.out.println("" + type);
> switch ((int)type) {
> case 0 : this.type = 'F';
> case ' ': this.type = 'F';
> case 'F': this.type = 'F';
> case 'f': this.type = 'F';
> case 'D': this.type = 'D';
> case 'd': this.type = 'D';
> case 'K': this.type = 'K';
> case 'k': this.type = 'K';
> default : throw new IllegalArgumentException("Forkert
> type-angivelse, F: Finans - D: Debitor - K: Kreditor");

Passende brug af break vil nok forbedre ydelsen en smule.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Det vil det formentligt ja. Men denne løsning burde i hvert fald virke.
At sætte breaks i sin switch burde være indlysende og for øvrigt god
skik. Men er faktisk ikke sikker på andet end at det vil compile ens...

The_MaXx


Thorbjoern Ravn Andersen wrote:

> The_MaXx <no-spam@spam-me.dk> writes:
>
>
>>Prøv:
>>
>>protected void setType(char type) throws IllegalArgumentException {
>> System.out.println("" + type);
>> switch ((int)type) {
>> case 0 : this.type = 'F';
>> case ' ': this.type = 'F';
>> case 'F': this.type = 'F';
>> case 'f': this.type = 'F';
>> case 'D': this.type = 'D';
>> case 'd': this.type = 'D';
>> case 'K': this.type = 'K';
>> case 'k': this.type = 'K';
>> default : throw new IllegalArgumentException("Forkert
>>type-angivelse, F: Finans - D: Debitor - K: Kreditor");
>
>
> Passende brug af break vil nok forbedre ydelsen en smule.
>

---

The_MaXx uttered:
> Det vil det formentligt ja. Men denne løsning burde i hvert fald virke.

Nej. Hvis du ikke sætter breaks vil den altid kaste en Exception (eller
IllegalArgumentException, i dit tilfælde).

Og så lige en henstilling til dig om ikke at topposte: Lad venligst være
med at topposte.

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

The_MaXx wrote:

> Det vil det formentligt ja. Men denne løsning burde i hvert fald virke.
> At sætte breaks i sin switch burde være indlysende og for øvrigt god
> skik. Men er faktisk ikke sikker på andet end at det vil compile ens...

Nej, langt fra! Jeg er også selv faldet i den fælde.

Java har arvet den tåbelige idé fra C, at når en "case" først er
opfyldt, bliver resten af koden udført indtil der kommer et "break".

Til gengæld kan koden skrives sammen til:

>>> switch ((int)type) {
>>> case 0 :
>>> case ' ':
>>> case 'F':
>>> case 'f': this.type = 'F'; break;
>>> case 'D':
>>> case 'd': this.type = 'D'; break;
>>> case 'K':
>>> case 'k': this.type = 'K'; break;
>>> default : throw new IllegalArgumentException("Forkert
>>> type-angivelse, F: Finans - D: Debitor - K: Kreditor");
>>> }

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein uttered:
> Java har arvet den tåbelige idé fra C, at når en "case" først er
> opfyldt, bliver resten af koden udført indtil der kommer et "break".

Det er skam ikke tåbeligt. Uden den feature havde du ikke kunne:

> Til gengæld kan koden skrives sammen til:
>
>>>> switch ((int)type) {
>>>> case 0 :
>>>> case ' ':
>>>> case 'F':
>>>> case 'f': this.type = 'F'; break;
>>>> case 'D':
>>>> case 'd': this.type = 'D'; break;
>>>> case 'K':
>>>> case 'k': this.type = 'K'; break;
>>>> default : throw new IllegalArgumentException("Forkert
>>>> type-angivelse, F: Finans - D: Debitor - K: Kreditor");
> >>> }

Det virker måske som overflødigt, men hvis der havde skulle udføres
10-20 liniers kode for hver case er det lige pludselig rart at kunne slå
cases sammen...

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy wrote:

>> Java har arvet den tåbelige idé fra C, at når en "case" først er
>>opfyldt, bliver resten af koden udført indtil der kommer et "break".
>
> Det er skam ikke tåbeligt. Uden den feature havde du ikke kunne:
> [...]

Ja, jeg tænkte jo nok, at den ikke ville gå ubemærket hen.

Jeg foretrækker en switch à la Pascal (hvor syntaksen i øvrigt
indledes med "case"). F.eks. ville jeg med:

switch (test) {
1, 2, 5 : statement1;
3, 4, 5 : { statement2; statement3; }
}

- ønske, at hvis test er 1 eller 2, udføres kun "statement1", hvis den
er 3 eller 4 udføres "statement2" og "statement3". Og hvis test er 5
udføres alle tre statements.

Det forekommer mere logisk (for mig) og sparer en masse "case" og
"break" statements. Desuden bevarer man stort set fleksibiliteten ved at
tillade samme værdi i flere "case" linjer.
Måske er det mere besværligt at optimere, men compileren skal jo
heller ikke have det for let...

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein uttered:
> Jeg foretrækker en switch à la Pascal (hvor syntaksen i øvrigt
> indledes med "case"). F.eks. ville jeg med:
>
> switch (test) {
> 1, 2, 5 : statement1;
> 3, 4, 5 : { statement2; statement3; }
> }
>
> - ønske, at hvis test er 1 eller 2, udføres kun "statement1", hvis den
> er 3 eller 4 udføres "statement2" og "statement3". Og hvis test er 5
> udføres alle tre statements.

Meget smart, men det har (i denne sammenhæng) intet at gøre med om man
skriver break eller ej efter - det er jo rent syntaktisk sukker (eller i
dette tilfælde måske det modsatte af sukker):

   switch (test){
    1,2,5 : statement; break;
    3,4,5 : {statement; statement; break; }
   }

Enig?

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy wrote:

> Meget smart, men det har (i denne sammenhæng) intet at gøre med om man
> skriver break eller ej efter - det er jo rent syntaktisk sukker (eller i
> dette tilfælde måske det modsatte af sukker):
>
>    switch (test){
>     1,2,5 : statement; break;
>     3,4,5 : {statement; statement; break; }
>    }
>
> Enig?

Sig til hvis jeg lige skal tage en kop kaffe og læse det igen, men
jeg er ikke helt sikker på hvad din kommentar går på?

Jeg så jo netop gerne, at "break" ikke var nødvendigt (og for
nemhedens skyld, kunne "case" også forsvinde).
Ud over det, ønsker jeg mig så, at
- samme værdi bliver tilladt i flere case-linjer.
- flere værdier bliver tilladt i samme case-linje.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein uttered:
> Jeg så jo netop gerne, at "break" ikke var nødvendigt (og for
> nemhedens skyld, kunne "case" også forsvinde).
> Ud over det, ønsker jeg mig så, at
> - samme værdi bliver tilladt i flere case-linjer.
> - flere værdier bliver tilladt i samme case-linje.

Yes, yes, vi er helt på samme side (okay, jeg er måske mere på din end
du er på min )

Det jeg (lidt klodset) prøvede at sige var, at dit ønske om at lade
samme værdi være tilladt i flere linier dybest set ikke har noget at
gøre med om der står break; eller ej efter cases.

Men observer en ting: Du vil gerne have "flere værdier tilladt i samme
case-linie". Det er nøjagtig det man har i Java, og det er derfor man
har break. Du har tilmed mulighed for at lade nogle cases dele kode
samtidig med at enkelte dele af casen har særskilt kode, fx:

switch(foo){
case 1: st;
case 2:
case 3: st; break;
}

Bottom line er jo at switches ikke er set bedre end i ML, hvor man kan
switche på alle datatyper. Vanvittigt praktisk.

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy wrote:

> Det jeg (lidt klodset) prøvede at sige var, at dit ønske om at lade
> samme værdi være tilladt i flere linier dybest set ikke har noget at
> gøre med om der står break; eller ej efter cases.

Det er korrekt. Ønsket om flere værdier i samme case-linje er jo også
primært affødt af at bevare funktionaliteten selv om syntaksen ændres.

> Men observer en ting: Du vil gerne have "flere værdier tilladt i samme
> case-linie". Det er nøjagtig det man har i Java, og det er derfor man
> har break.

Mja, - jeg vil jo sige, at flere "case" linjer leder til samme kode.

- Men vi er vist ganske enige om hvordan tingene er - og
tilsyneladende også om hvordan de burde være...

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein <jstein@image.dk> writes:

> - ønske, at hvis test er 1 eller 2, udføres kun "statement1", hvis den
> er 3 eller 4 udføres "statement2" og "statement3". Og hvis test er 5
> udføres alle tre statements.

Tjah, men sådan er det desværre bare ikke :(

Java har efter min mening lagt sig alt for tæt op af C. Det er
undertiden ret irriterende, men det lærer man at leve med.

--
Thorbjørn

---

Thorbjoern Ravn Andersen uttered:
> Java har efter min mening lagt sig alt for tæt op af C. Det er
> undertiden ret irriterende, men det lærer man at leve med.

Jeg synes den klart mest irriterende "feature" i Java er at man kun kan
switch'e på integers. Tal om en designfejl der vil frem...

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> wrote:

> Jeg synes den klart mest irriterende "feature" i Java er at man kun kan
> switch'e p? integers. Tal om en designfejl der vil frem...

Det er ret ubehaendigt. Scheme har eksempeltvist baade (case ...), der
switcher paa konstanter og (cond ...) der i realiteten er en if ... then
.... else chain ala

if (cond1) then action1
elseif (cond2) then action2
elseif (cond3) then action3
....
else default-case

Forskellen er at en ren konstantbaseret switch er rarere set ud fra et
optimeringsmaessigt synspunkt.

--
j.

---

On Mon, 04 Oct 2004 21:11:33 +0200, Jesper Louis Andersen wrote:

>
> if (cond1) then action1
> elseif (cond2) then action2
> elseif (cond3) then action3
> ...
> else default-case
>
Øhh, ovenstående kan da udføres i alle procedurale sprog??.
Hvad angår switch, vil jeg også mene, at det er en begrænsning, at man
ikke kan switche på string. Det kan man dog komme udenom ved at indrette
sin kode efter det.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
You may my glories and my state dispose,
But not my griefs; still am I king of those.
      -- William Shakespeare, "Richard II"

---

On Mandag 04 oktober 2004 21:25, Michael Rasmussen wrote:

> On Mon, 04 Oct 2004 21:11:33 +0200, Jesper Louis Andersen wrote:
>
>>
>> if (cond1) then action1
>> elseif (cond2) then action2
>> elseif (cond3) then action3
>> ...
>> else default-case
>>
> Øhh, ovenstående kan da udføres i alle procedurale sprog??.
> Hvad angår switch, vil jeg også mene, at det er en begrænsning, at man
> ikke kan switche på string. Det kan man dog komme udenom ved at indrette
> sin kode efter det.
>

Jesper henviste til konstruktionerne (case ...) og (cond ...).

Konstruktionen (cond ...) har f.eks. følgende syntaks:

(cond
(p1 e1)
(p2 e2)
...
(else en)
)

--
Jonas Kongslund

---

Michael Rasmussen <mir@miras.org> writes:

> Hvad angår switch, vil jeg også mene, at det er en begrænsning, at man
> ikke kan switche på string. Det kan man dog komme udenom ved at indrette
> sin kode efter det.

Du kan jo switche på strengens hashkode. Alternativt lave en hashmap
fra streng til heltal, og så switche på heltallet.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen <nospam0000@c.dk> wrote:

> Du kan jo switche p? strengens hashkode. Alternativt lave en hashmap
> fra streng til heltal, og s? switche p? heltallet.

Minder mig om:

http://www.dina.dk/~sestoft/papers/performance.pdf

Ideen med at lave hashmappet statisk er ikke helt tosset ;)

--
j.

---

Jesper Louis Andersen uttered:
> Minder mig om:
>
> http://www.dina.dk/~sestoft/papers/performance.pdf

Kanon, den kendte jeg ikke. Og så er det endda min specialevejleder -
sheesh :)

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> Jeg synes den klart mest irriterende "feature" i Java er at man kun kan
> switch'e på integers. Tal om en designfejl der vil frem...

Tjah. Eftersom det læner sig op af en monster-goto-tabel, så er det
vel naturligt at den ikke kan eksplodere helt vildt. Der er jo også
en øvre grænse på hvor stor en klasse kan være.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen uttered:
>> Jeg synes den klart mest irriterende "feature" i Java er at man kun kan
>> switch'e på integers. Tal om en designfejl der vil frem...
>
> Tjah. Eftersom det læner sig op af en monster-goto-tabel, så er det
> vel naturligt at den ikke kan eksplodere helt vildt. Der er jo også
> en øvre grænse på hvor stor en klasse kan være.

Ikke forstået? Hvad er det der eksploderer? Hvorfor er der en øvre
grænse på hvor stor en klasse kan være, og hvad er den målt i?

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> Ikke forstået? Hvad er det der eksploderer? Hvorfor er der en øvre
> grænse på hvor stor en klasse kan være, og hvad er den målt i?

Den oplagte måde at implementere en switch er noget i stil med (jeg
aner ikke om det sker sådan - det er rent gætteværk):

switch(ch) of
0: foo(); break;
1: bar(); break
1000: zoo(); break;
default: zap(); break;
}

.....
jump jumptabel[ch]
jumptabel:
addressof foo // 0
addressof bar // 1
addressof zap // 2
addressof zap // 3
addressof zap // 4
addressof zap // 5
....
addressof zap // 999
addressof zoo // 1000
foo:
...
jump endswitch // break
bar: ...
jump endswitch // break
zoo: ...
jump endswitch // break
zap: ...
jump endswitch // break
endswitch:
...


Som du kan se, så for at lave den simplest mulige hoptabel, så _fylder_
tabellen modsvarende det højeste værdi i switchen.

Så vidt jeg ved, kan et segment i Java ikke fylde mere end 64 Kb, og
hvis en adresse derfor er 16-bit, så er der en faktisk grænse på
omkring 32000 indgange i en switch.

Som sagt - rent gætværk.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen wrote:

> Den oplagte måde at implementere en switch er noget i stil med (jeg
> aner ikke om det sker sådan - det er rent gætteværk):

Jeg fant lige en artikel om compilering af if- og switch-udtryk:
http://www.eventhelix.com/RealtimeMantra/Basics/CToAssemblyTranslation3.htm

Som artiklen nævner, er det oplagt en compiler-opgave at vælge den
bedste oversættelse. - Og et område, hvor man i høj grad skal prioritere
mellem hastighed og størrelse.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Thorbjoern Ravn Andersen uttered:
> Den oplagte måde at implementere en switch er noget i stil med (jeg
> aner ikke om det sker sådan - det er rent gætteværk):
[snip]
> Som du kan se, så for at lave den simplest mulige hoptabel, så _fylder_
> tabellen modsvarende det højeste værdi i switchen.

Mmm. Jeg tvivler på at compileren laver den simplest mulige hoptabel.

> Så vidt jeg ved, kan et segment i Java ikke fylde mere end 64 Kb, og
> hvis en adresse derfor er 16-bit, så er der en faktisk grænse på
> omkring 32000 indgange i en switch.

Hvad har det at gøre med om man kan switche på strenge eller ej?

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> > Som du kan se, så for at lave den simplest mulige hoptabel, så _fylder_
> > tabellen modsvarende det højeste værdi i switchen.
>
> Mmm. Jeg tvivler på at compileren laver den simplest mulige
> hoptabel.

Hvad gør den så?

> > Så vidt jeg ved, kan et segment i Java ikke fylde mere end 64 Kb, og
> > hvis en adresse derfor er 16-bit, så er der en faktisk grænse på
> > omkring 32000 indgange i en switch.
>
> Hvad har det at gøre med om man kan switche på strenge eller ej?

Det har noget at gøre med om det giver mening højest at kunne switche
på en int eller om en long også var mulig.

Hvordan havde du tænkt dig at en switch på strenge skulle fungere
(altså i den oversatte kode)? Som en række if-elseif?


--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen uttered:
>> Mmm. Jeg tvivler på at compileren laver den simplest mulige
>> hoptabel.
>
> Hvad gør den så?

Vi kan jo prøve at tjekke:

public class Test{
public static void main(String[] args) throws Exception{
int x = Integer.parseInt(args[0]);
switch(x){
case 0: ;
case 1: ;   break;
case 10: ; break;
default: ;
}
}
}

$ javac Test.java && javap -c -verbose Test

[output snippet til det interessante:]

public static void main(java.lang.String[])
   throws java.lang.Exception;
Code:
Stack=2, Locals=2, Args_size=1
0:   aload_0
1:   iconst_0
2:   aaload
3:   invokestatic   #2; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I
6:   istore_1
7:   iload_1
8:   lookupswitch{ //3
      0: 44;
      1: 44;
      10: 47;
      default: 50
   }
44:   goto 50
47:   goto 50
50:   return
LineNumberTable:
line 3: 0
line 4: 7
line 6: 44
line 7: 47
line 10: 50

.... så der er kun det antal entries som du har i switchen.

> Hvordan havde du tænkt dig at en switch på strenge skulle fungere
> (altså i den oversatte kode)? Som en række if-elseif?

Ja.

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> Vi kan jo prøve at tjekke:

Det er jo snyd at bringe fakta på bordet.

> 8:   lookupswitch{ //3
>       0: 44;
>       1: 44;
>       10: 47;
>       default: 50

Det jeg nu uvilkårligt tænker, er at Java ByteCode er lavet til at
være kompakt. Hvordan mon så HotSpotten (som jo faktisk kører det
her) laver kode? Er der en let måde at se det på?


>
> > Hvordan havde du tænkt dig at en switch på strenge skulle fungere
> > (altså i den oversatte kode)? Som en række if-elseif?
>
> Ja.

Dvs der er absolut ingen forskel på at lave en if-elseif-osv
konstruktion ud over lidt syntakssukker?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen uttered:
> Det er jo snyd at bringe fakta på bordet.

Ja, det har ødelagt mangt en flamewar :)

>> 8:   lookupswitch{ //3
>>       0: 44;
>>       1: 44;
>>       10: 47;
>>       default: 50
>
> Det jeg nu uvilkårligt tænker, er at Java ByteCode er lavet til at
> være kompakt. Hvordan mon så HotSpotten (som jo faktisk kører det
> her) laver kode? Er der en let måde at se det på?

Pas, her står jeg af. Jeg har aldrig kigget dybere i JVM end den
bytecode den afvikler.

>> > Hvordan havde du tænkt dig at en switch på strenge skulle fungere
>> > (altså i den oversatte kode)? Som en række if-elseif?
>>
>> Ja.
>
> Dvs der er absolut ingen forskel på at lave en if-elseif-osv
> konstruktion ud over lidt syntakssukker?

Ikke fra hvor jeg står, men herfra kan jeg altså heller ikke se hvordan
det afvikles i JVM.

Det jeg lige tænker måske kunne være interessant er flg.:

1) ML kan switche på alle datatyper.
2) Java kan kun switche på int.
3) Vi har en ML -> Java bytecode compiler.

1+2+3 = hmm...

Jeg vil lige se hvordan den er sat til at generere bytecoden. Be right
back.

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

On Tirsdag 05 oktober 2004 23:33, Kristian Thy wrote:

> 2) Java kan kun switche på int.

Java kan switche på char, byte, short eller int.

--
Jonas Kongslund

---

Jonas Kongslund uttered:
>> 2) Java kan kun switche på int.
>
> Java kan switche på char, byte, short eller int.

Du har fuldstændig ret - se fx definitionen her:
<URL:http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#35518>

Jeg troede faktisk at man switchede på int, og dermed _implicit_ på
byte, short og char fordi de kan castes til en int. Forskellen er
fuldstændig akademisk, ja :)

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Thorbjoern Ravn Andersen skrev:

>Den oplagte måde at implementere en switch er noget i stil med (jeg
>aner ikke om det sker sådan - det er rent gætteværk):

Oplagt? Det synes jeg ikke.

Nemt? Ja, i høj grad.

En switchmulighed med strenge kræver kun et ekstra mellemled hvor
hver streng tildeles en heltalsværdi. Det kan ikke være svært at
implementere. Sammenligningen bliver lidt mere kompleks, men
rutinen findes jo allerede.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamius@lundhansen.dk> writes:

> >Den oplagte måde at implementere en switch er noget i stil med (jeg
> >aner ikke om det sker sådan - det er rent gætteværk):
>
> Oplagt? Det synes jeg ikke.

Det kan måske skyldes at du ikke har haft særlig meget
maskinkodeprogrammering? Igen rent gætværk :)

> En switchmulighed med strenge kræver kun et ekstra mellemled hvor
> hver streng tildeles en heltalsværdi. Det kan ikke være svært at
> implementere. Sammenligningen bliver lidt mere kompleks, men
> rutinen findes jo allerede.

Jeg går ud fra at vi ikke snakker om at ændre selve Java-sproget?

Det er ikke svært at implementere nogen af de ting vi har snakket om,
men spørgsmålet er _hvordan_ det skal gøres for at være sikker på at
det kører fornuftigt både ved små og store konstruktioner. Den af mig
beskrevne hoptabel udmærker sig ved at tage den samme tid uanset hvor
meget vi snakker om.

Nu snakker du om at tildele en streng en heltalsværdi (hvilket var
hvad jeg mente med et hashmap med strengen som nøgle og en Integer
som værdi), og her er det meget vigtigt hvordan denne tildeling sker.
Kan du ikke forklare hvad du havde tænkt dig?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen uttered:
> Den af mig beskrevne hoptabel udmærker sig ved at tage den samme tid
> uanset hvor meget vi snakker om.

Hvis vi var bekymret om køretid ville vi ikke programmere i Java

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> > Den af mig beskrevne hoptabel udmærker sig ved at tage den samme tid
> > uanset hvor meget vi snakker om.
>
> Hvis vi var bekymret om køretid ville vi ikke programmere i Java

Hotspotprogrammoerene bekymrer sig formentlig om koeretid.

Men det er vi ikke, og vi er bare ligeglade :)

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Kristian Thy wrote:

>
> Hvis vi var bekymret om køretid ville vi ikke programmere i Java

På Linux og lignende platforme afvikles mange java-programmer faktisk
kun marginalt langsommere end C++.
Problemet i windows er den manglende åbenhed om windows kode der gør at
det er svært at optimere Java til platformen...

Har info til at underbygge denne påstand da jeg fandt en
hastighedssammenligning på gængse algoritmer i Java og C++ på nettet og
i et par tilfælde var Java endda hurtigere, men det var der så nogle
forklaringer på. Kan bare ikke huske siden, men kan nok finde den hvis
jeg vil bruge tiden.

The_MaXx

---

On Wed, 06 Oct 2004 17:53:18 +0200, The_MaXx wrote:

>
> Har info til at underbygge denne påstand da jeg fandt en
> hastighedssammenligning på gængse algoritmer i Java og C++ på nettet og
> i et par tilfælde var Java endda hurtigere, men det var der så nogle
> forklaringer på. Kan bare ikke huske siden, men kan nok finde den hvis
> jeg vil bruge tiden.
Jeg har faktisk eksempler på kode, der afvikles hurtigere i Java end
ditto C/C++ på Linux. Hvis det har interesse, kan jeg offentliggøre
koden?

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Q:   What's a light-year?
A:   One-third less calories than a regular year.

---

Michael Rasmussen <mir@miras.org> writes:

> Jeg har faktisk eksempler på kode, der afvikles hurtigere i Java end
> ditto C/C++ på Linux. Hvis det har interesse, kan jeg offentliggøre
> koden?

Jeg vil gerne se det, og dine målinger. Jeg går ud fra at begge
kodestumper er lavet "så godt som muligt"?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

On Thu, 07 Oct 2004 00:28:29 +0200, Thorbjoern Ravn Andersen wrote:

>
> Jeg vil gerne se det, og dine målinger. Jeg går ud fra at begge
> kodestumper er lavet "så godt som muligt"?
Målinger laves i programmerne. De udfører Fibonaci(x); x gives som
argument til programmet. Prøv f.eks. med 45 som argument.

<java>
import java.io.*;

public class Fibonaci extends Thread {

   public static void main(String args[])
   {
      IterThread thread2;
      RecurThread thread1;
      long i, tmp = 0;

      if (args.length < 1) {
         System.out.println("Provide a limit!");
         return;
      }
      else {
         tmp = Long.parseLong(args[0]);
         System.out.println("Starting recursive thread");
         thread1 = new RecurThread("Recursive", tmp);
         System.out.println("Starting iterative thread");
         thread2 = new IterThread("Iterative", tmp);
         thread1.start();
         thread2.start();
      }
   }
}

class IterThread extends Thread {

   private long times;

   public IterThread(String name, long tmp)
   {
      super(name);
      times = tmp;
   }

   public void run()
   {
      long old_number; /* previous Fibonacci number */
      long current_number; /* current Fibonacci number */
      long next_number; /* next number in the series */
      long i;
   
      /* start things out */
      long start = System.currentTimeMillis();
      old_number = 1;
      current_number = 1;
      
      for(i = 2; i <= times; i++)   {
         next_number = current_number + old_number;
         old_number = current_number;
         current_number = next_number;
      }
      System.err.println("Execution time for " + getName()
            + " thread: " + ((System.currentTimeMillis() - start) / 1000)
            + " sec.");
   }

}

class RecurThread extends Thread {

   private long times;

   private long doRec(long n) {
      if (n < 2)
         return 1;
      else
         return doRec(n - 1) + doRec(n - 2);
   }

   public RecurThread(String name, long tmp)
   {
      super(name);
      times = tmp;
   }

   public void run()
   {
      long iter;
      long start = System.currentTimeMillis();

      for(iter = 0; iter < times; iter++)
         doRec(iter);
      System.err.println("Execution time for " + getName()
            + " thread: " + ((System.currentTimeMillis() - start) / 1000)
            + " sec.");
   }

}
</java>

<C/C++>
/* fibonaci.cpp is copyright 2004, Michael Rasmussen. */
/* The source is provided as is but is licensed under GPL */
#include <stdio.h>
#include <time.h>
#include <pthread.h>
#include <iostream>
using namespace std;

struct fib_arg { long long num; };
         
void *Iterative(void *arg) {
   long long old_number; /* previous Fibonacci number */
   long long current_number; /* current Fibonacci number */
   long long next_number; /* next number in the series */
   long i;
   long long times = ((fib_arg *)arg)->num;
   time_t start;
   
   /* start things out */
   start = time(NULL);
   old_number = 1;
   current_number = 1;
      
   for(i = 2; i <= times; i++)   {
      next_number = current_number + old_number;
      old_number = current_number;
      current_number = next_number;
   }
   cerr << "Execution time for iterativ function: "
       << difftime(time(NULL), start) << " sec." << endl;
   return 0;
}

long long doRec(long long n) {
   if (n < 2)
      return 1;
   else
      return doRec(n - 1) + doRec(n - 2);
}

void *Recursive(void *arg) {
   long iter;
   long long times = ((fib_arg *)arg)->num;
   time_t start;

   start = time(NULL);
   for(iter = 0; iter < times; iter++)
      doRec(iter);
   cerr << "Execution time for recursiv function: "
       << difftime(time(NULL), start) << " sec." << endl;
   return 0;
}

int main(int argc, char *argv[])
{
   long i, tmp = 0;
   pthread_t recur, iter;

   if (argc < 2) {
      puts("Provide a limit!\n");
      return -1;
   }
   else {
      for(i = 0; i < (long) strlen(argv[1]); i++)
         tmp = tmp * 10 + argv[1][i] - '0';
      puts("Starting recursive thread");
      struct fib_arg init = {tmp};
      pthread_create(&recur, NULL, &Recursive, &init);
      puts("Starting iterative thread");
      pthread_create(&iter, NULL, &Iterative, &init);
      pthread_join(recur, NULL);
      pthread_join(iter, NULL);
      return 0;
   }
}
</C/C++>

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Troubled day for virgins over 16 who are beautiful and wealthy and live
in eucalyptus trees.

---

Thorbjoern Ravn Andersen skrev:

>Det kan måske skyldes at du ikke har haft særlig meget
>maskinkodeprogrammering?

Det var faktisk det første 'programmeringssprog' jeg lærte til
bunds (symbolsk maskinkode til en 8080'er - selvstudium).

>> En switchmulighed med strenge kræver kun et ekstra mellemled hvor
>> hver streng tildeles en heltalsværdi. Det kan ikke være svært at
>> implementere. Sammenligningen bliver lidt mere kompleks, men
>> rutinen findes jo allerede.

>Jeg går ud fra at vi ikke snakker om at ændre selve Java-sproget?

Jeg troede at vi diskuterede hvordan man kunne have implementeret
switch i Java så man også kunne switche på strenge.

Strengene lagres på stribe. En pointertabel holder rede på deres
adresser (da de ikke nødvendigvis er lige lange).

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Thorbjoern Ravn Andersen uttered:
> Kristian Thy <thy@it.edu> writes:
>
>> Jeg synes den klart mest irriterende "feature" i Java er at man kun kan
>> switch'e på integers. Tal om en designfejl der vil frem...
>
> Tjah. Eftersom det læner sig op af en monster-goto-tabel, så er det
> vel naturligt at den ikke kan eksplodere helt vildt. Der er jo også
> en øvre grænse på hvor stor en klasse kan være.

Vi er overraskende nok ikke de første der diskuterer det her.

<URL:http://yost.com/computers/java/string-switch/>

\\kristian
--
<URL:http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt>
<URL:http://home.att.net/~jbcole/humor/Microsoft_patents.htm>

---

Kristian Thy <thy@it.edu> writes:

> <URL:http://yost.com/computers/java/string-switch/>

Åbenbart ikke. Man må jo undres over at Sun laver alt muligt andet,
men ikke noget der kan lave pæn og læseligkode.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Jonathan Stein <jstein@image.dk> wrote:

> M?ske er det mere besv?rligt at optimere, men compileren skal jo
> heller ikke have det for let...

Det tror jeg nu ikke det er, med den viden om compilerteori jeg har.

--
j.

---

Jesper Louis Andersen wrote:

>> M?ske er det mere besv?rligt at optimere, men compileren skal jo
>>heller ikke have det for let...
>
> Det tror jeg nu ikke det er, med den viden om compilerteori jeg har.

Umiddelbart synes jeg heller ikke det skulle være en kæmpe opgave,
men omvendt har jeg altid undret mig over, at man nogen sinde har valgt
en anden opbygning af switch-strukturen.
Jeg havde forestillet mig, at en compiler-nørd en dag ville slå mig
med det argument, så jeg ville hellere nævne det på forhånd.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein <jstein@image.dk> wrote:

> Umiddelbart synes jeg heller ikke det skulle v?re en k?mpe opgave,
> men omvendt har jeg altid undret mig over, at man nogen sinde har valgt
> en anden opbygning af switch-strukturen.

Saa laenge det er konstanter, saa er det nemt nok. Som en start kan
man oversaette til en if...then...else konstruktion, og da logisk
eller er en del af de fleste sprog ville det vaere meget nemt at tage
haand om.

Hvis switchen bliver stoerre, saa laver man som regel en jump-tabel, men
ogsaa her gaelder det at det er en rimeligt triviel opgave at lade
flere jump-slots indeholde hop til samme stump kode.

Det kan selvfoelgeligt emuleres i C-lignende sprog med passende brug
af ''break'' keywordet, men det er nu paenere at have en Pascal-lignende
konstruktion efter min mening.

--
j.

---

Jesper Louis Andersen wrote:

> Det kan selvfoelgeligt emuleres i C-lignende sprog med passende brug
> af ''break'' keywordet, men det er nu paenere at have en Pascal-lignende
> konstruktion efter min mening.

Jamen så er vi vist også ganske enige.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

The_MaXx <no-spam@spam-me.dk> writes:

> Det vil det formentligt ja. Men denne løsning burde i hvert fald
> virke. At sætte breaks i sin switch burde være indlysende og for
> øvrigt god skik. Men er faktisk ikke sikker på andet end at det vil
> compile ens...

Det gør den nu ikke - havde du testet den inden du smed den ud på
nettet, ville du have opdaget det.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen wrote:

> The_MaXx <no-spam@spam-me.dk> writes:
>
>
>>Det vil det formentligt ja. Men denne løsning burde i hvert fald
>>virke. At sætte breaks i sin switch burde være indlysende og for
>>øvrigt god skik. Men er faktisk ikke sikker på andet end at det vil
>>compile ens...
>
>
> Det gør den nu ikke - havde du testet den inden du smed den ud på
> nettet, ville du have opdaget det.

Nej jeg har ikke testet. Gik lidt stærkt. Men som jeg skriver er det god
skik altid at bruge break; og det gør jeg selv så vidste faktisk ikke om
det var muligt at lave det anderledes.

The_MaXx

---

In <41616f53$0$159$edfadb0f@dtext01.news.tele.dk> The_MaXx <no-spam@spam-me.dk> writes:

>Det vil det formentligt ja. Men denne løsning burde i hvert fald virke.
>At sætte breaks i sin switch burde være indlysende og for øvrigt god
>skik. Men er faktisk ikke sikker på andet end at det vil compile ens...

>The_MaXx

Nej, du kommer jo ned i default-delen uden en break.

/Martin

---

> Nej, du kommer jo ned i default-delen uden en break.
>
> /Martin


Ja nemlig. Var vist lidt træt i mandags (var faktisk syg *G*)

The_MaXx